Tom Lane wrote:
> Robert Haas writes:
> > On Wed, Sep 22, 2010 at 4:04 PM, Alvaro Herrera
> > wrote:
> >> As far as I can see, I need to go to the master clone, run a checkout
> >> and pull on each branch, and *then* a pull on the local clone updates to
> >> the latest head on that branch. ?It is
Excerpts from Alvaro Herrera's message of mié sep 22 16:57:24 -0400 2010:
> Apparently the only difference is that the initial clone needs to be
> done with --bare:
> git clone --bare ssh://g...@gitmaster.postgresql.org/postgresql.git
Okay, it works with --bare --mirror. I'm going to update
On 09/22/2010 04:55 PM, Tom Lane wrote:
(In particular, I'm avoiding Andrew's preferred alternative with the
extra local repository; I don't want an asynchronous buffer between me
and the real repository. I guess if you had a really bad network
connection it could be useful, but considering
Excerpts from Alvaro Herrera's message of mié sep 22 16:48:28 -0400 2010:
> Excerpts from Aidan Van Dyk's message of mié sep 22 16:20:15 -0400 2010:
> > I think what you want in this case (where you have a local "master"
> > repositroy, and clone your work of them) is to make your master
> > repos
Robert Haas writes:
> On Wed, Sep 22, 2010 at 4:04 PM, Alvaro Herrera
> wrote:
>> As far as I can see, I need to go to the master clone, run a checkout
>> and pull on each branch, and *then* a pull on the local clone updates to
>> the latest head on that branch. It is not enough to pull when the
Excerpts from Aidan Van Dyk's message of mié sep 22 16:20:15 -0400 2010:
> On Wed, Sep 22, 2010 at 4:04 PM, Alvaro Herrera
> wrote:
>
> > As far as I can see, I need to go to the master clone, run a checkout
> > and pull on each branch, and *then* a pull on the local clone updates to
> > the late
On Wed, Sep 22, 2010 at 4:04 PM, Alvaro Herrera
wrote:
> Excerpts from Robert Haas's message of mar sep 21 13:43:28 -0400 2010:
>
>> Oops. I left out a step. Fixed.
>
> Hmm, it still doesn't work. I can pull into the normal clone and it
> works, but when I run a "git pull" in one of the local c
On Wed, Sep 22, 2010 at 4:04 PM, Alvaro Herrera
wrote:
> As far as I can see, I need to go to the master clone, run a checkout
> and pull on each branch, and *then* a pull on the local clone updates to
> the latest head on that branch. It is not enough to pull when the
> master branch is checked
Excerpts from Robert Haas's message of mar sep 21 13:43:28 -0400 2010:
> Oops. I left out a step. Fixed.
Hmm, it still doesn't work. I can pull into the normal clone and it
works, but when I run a "git pull" in one of the local clones, it says
it's up to date even when there are commits that I
At 2010-09-21 12:45:20 -0400, t...@sss.pgh.pa.us wrote:
>
> Having done that, I now realize that the historical tag "release-6-3"
> is identical to what I applied as REL6_3. It would probably be
> reasonable to remove "release-6-3", if that's still possible, but
> I'm not clear on how.
You can s
On 09/21/2010 02:10 PM, Tom Lane wrote:
Robert Haas writes:
On Tue, Sep 21, 2010 at 1:32 PM, Alvaro Herrera
wrote:
I tried to follow the instructions on the Wiki but they didn't work.
Oops. I left out a step. Fixed.
While we're discussing possible errors on that page ... at the bottom
On 21/09/10 21:10, Tom Lane wrote:
While we're discussing possible errors on that page ... at the bottom of
the page under the "multiple workdirs" alternative are these recipes for
re-syncing your local checkouts:
git checkout REL9_0_STABLE
git pull
git checkout master
Robert Haas writes:
> On Tue, Sep 21, 2010 at 1:32 PM, Alvaro Herrera
> wrote:
>> I tried to follow the instructions on the Wiki but they didn't work.
> Oops. I left out a step. Fixed.
While we're discussing possible errors on that page ... at the bottom of
the page under the "multiple workdi
On Tue, Sep 21, 2010 at 1:32 PM, Alvaro Herrera
wrote:
> Excerpts from Magnus Hagander's message of lun sep 20 12:49:28 -0400 2010:
>
>> Committers can (and should! please test!) clone from git clone
>> ssh://g...@gitmaster.postgresql.org/postgresql.git.
>>
>> Please do *NOT* commit or push anythi
On 21/09/10 20:32, Alvaro Herrera wrote:
What I find is that after doing the local clone for the branch, i.e.
git clone postgresql REL9_0_STABLE
this clones only the "master" branch somehow, not the other branches; so
when I later run
git checkout REL9_0_STABLE
on that clone, it fails with
Excerpts from Magnus Hagander's message of lun sep 20 12:49:28 -0400 2010:
> Committers can (and should! please test!) clone from git clone
> ssh://g...@gitmaster.postgresql.org/postgresql.git.
>
> Please do *NOT* commit or push anything to this repository yet though:
> The repo is there - all th
Magnus Hagander writes:
> On Tue, Sep 21, 2010 at 18:47, Tom Lane wrote:
>> True. We will be creating four or five tags at a time during
>> back-branch update cycles, but those might well arrive in separate
>> pushes anyway, depending on how Marc chooses to arrange his workflow.
> I could look
On Tue, Sep 21, 2010 at 18:47, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Sep 21, 2010 at 12:31 PM, Tom Lane wrote:
>>> Done. The commit hook seems to be a bit verbose about that sort of
>>> thing ... is it worth trying to collapse the pgsql-committers messages
>>> into one email?
>
>> I
Robert Haas writes:
> On Tue, Sep 21, 2010 at 12:31 PM, Tom Lane wrote:
>> Done. The commit hook seems to be a bit verbose about that sort of
>> thing ... is it worth trying to collapse the pgsql-committers messages
>> into one email?
> I was thinking the same thing, until I realized that pushi
I wrote:
> Magnus Hagander writes:
>> Go for it.
> Done.
Having done that, I now realize that the historical tag "release-6-3"
is identical to what I applied as REL6_3. It would probably be
reasonable to remove "release-6-3", if that's still possible, but
I'm not clear on how.
On Tue, Sep 21, 2010 at 12:31 PM, Tom Lane wrote:
> Magnus Hagander writes:
>> On Tue, Sep 21, 2010 at 05:38, Tom Lane wrote:
>>> For the archives' sake, below are the missing historical tags that
>>> match available tarballs, plus re-instantiation of the Release_2_0
>>> and Release_2_0_0 tags o
Magnus Hagander writes:
> On Tue, Sep 21, 2010 at 05:38, Tom Lane wrote:
>> For the archives' sake, below are the missing historical tags that
>> match available tarballs, plus re-instantiation of the Release_2_0
>> and Release_2_0_0 tags on non-manufactured commits. I will push
>> these up to t
On Tue, Sep 21, 2010 at 05:38, Tom Lane wrote:
> Magnus Hagander writes:
>> Ok, I've pushed a new repository to both gitmaster and the
>> postgresql-migration.git mirror, that has this setting.
>> NOTE! Do a complete wipe of your repository before you clone this
>> again - it's a completely new r
Magnus Hagander writes:
> Ok, I've pushed a new repository to both gitmaster and the
> postgresql-migration.git mirror, that has this setting.
> NOTE! Do a complete wipe of your repository before you clone this
> again - it's a completely new repo that will have different SHA1s.
AFAICT this versi
On Mon, Sep 20, 2010 at 20:05, Magnus Hagander wrote:
> On Mon, Sep 20, 2010 at 7:57 PM, Magnus Hagander wrote:
>> On Mon, Sep 20, 2010 at 19:49, Tom Lane wrote:
>>> Magnus Hagander writes:
On Mon, Sep 20, 2010 at 19:34, Tom Lane wrote:
> Please fix and re-run.
>>>
Uh, what the h
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> This is not even close to matching the tarballs :-(. Seems to be a
> >> locale problem: the diffs look like
> >>
> >> 1c1
> >> < /* $PostgreSQL: pgsql/contrib/citext/citext.sql.in,v 1.3 2008/09/05
> >> 18:25:16 tgl Exp $ */
> >> -
Peter Eisentraut writes:
> On mån, 2010-09-20 at 15:09 -0400, Tom Lane wrote:
>> I wouldn't be against that necessarily if we were
>> keeping the keywords and not getting rid of them. But since we are
>> going to get rid of them going forward, I think what we want this
>> conversion to do is mat
On 09/20/2010 09:06 PM, Tom Lane wrote:
Stefan Kaltenbrunner writes:
http://lists.nongnu.org/archive/html/info-cvs/2004-07/msg00106.html
is what I'm refering too and what the debian people provided a patch to
work around for(starting with1:1.12.9-17 in 2005) - nut sure why you are
not seeing it
On mån, 2010-09-20 at 15:09 -0400, Tom Lane wrote:
> I wouldn't be against that necessarily if we were
> keeping the keywords and not getting rid of them. But since we are
> going to get rid of them going forward, I think what we want this
> conversion to do is match what's in the historical tarba
Bruce Momjian writes:
> Tom Lane wrote:
>> This is not even close to matching the tarballs :-(. Seems to be a
>> locale problem: the diffs look like
>>
>> 1c1
>> < /* $PostgreSQL: pgsql/contrib/citext/citext.sql.in,v 1.3 2008/09/05
>> 18:25:16 tgl Exp $ */
>> ---
> /* $PostgreSQL: pgsql/contrib
Stefan Kaltenbrunner writes:
> http://lists.nongnu.org/archive/html/info-cvs/2004-07/msg00106.html
> is what I'm refering too and what the debian people provided a patch to
> work around for(starting with1:1.12.9-17 in 2005) - nut sure why you are
> not seeing it...
Hm, that is talking about th
Tom Lane wrote:
> Magnus Hagander writes:
> > Since there haven't been any commits in cvs during the day, the test
> > conversoin I created after lunch should be identical to a new one I'd
> > run now, so let's use that one :-)
>
> This is not even close to matching the tarballs :-(. Seems to be
On 09/20/2010 08:33 PM, Tom Lane wrote:
Stefan Kaltenbrunner writes:
On 09/20/2010 08:21 PM, Tom Lane wrote:
Well, I'm testing with an unmodified copy of 1.12.13, and I got output
matching our historical tarballs. So I'm blaming debian for this one.
As far as I know magnus is using a debia
Stefan Kaltenbrunner writes:
> On 09/20/2010 08:21 PM, Tom Lane wrote:
>> Well, I'm testing with an unmodified copy of 1.12.13, and I got output
>> matching our historical tarballs. So I'm blaming debian for this one.
> As far as I know magnus is using a debian based CVS server for his
> testin
On 09/20/2010 08:21 PM, Tom Lane wrote:
Stefan Kaltenbrunner writes:
On 09/20/2010 08:05 PM, Magnus Hagander wrote:
debian applies a patch to change it. If I set DateStyle=old in
CVSROOT/config, cvs export behaves sanely. I'll re-run with that
setting.
actually as I understand it the behavi
On Monday 20 September 2010 20:22:55 Tom Lane wrote:
> Andres Freund writes:
> > On Monday 20 September 2010 20:15:50 Tom Lane wrote:
> >> BTW, while poking around in this morning's attempt I noticed
> >> .git/description, containing
> >>
> >> Unnamed repository; edit this file 'description' to n
Magnus Hagander writes:
> On Mon, Sep 20, 2010 at 20:15, Tom Lane wrote:
>> BTW, while poking around in this morning's attempt I noticed
>> .git/description, containing
>>
>> Unnamed repository; edit this file 'description' to name the repository.
> That said, where was it set to that? A locall
Andres Freund writes:
> On Monday 20 September 2010 20:15:50 Tom Lane wrote:
>> BTW, while poking around in this morning's attempt I noticed
>> .git/description, containing
>>
>> Unnamed repository; edit this file 'description' to name the repository.
>>
>> No idea if this is shown anywhere or i
Stefan Kaltenbrunner writes:
> On 09/20/2010 08:05 PM, Magnus Hagander wrote:
>> debian applies a patch to change it. If I set DateStyle=old in
>> CVSROOT/config, cvs export behaves sanely. I'll re-run with that
>> setting.
> actually as I understand it the behaviour changed in cvs 1.12.x and
>
On Mon, Sep 20, 2010 at 20:15, Tom Lane wrote:
> BTW, while poking around in this morning's attempt I noticed
> .git/description, containing
>
> Unnamed repository; edit this file 'description' to name the repository.
>
> No idea if this is shown anywhere or if there is any practical way to
> chan
On Monday 20 September 2010 20:15:50 Tom Lane wrote:
> BTW, while poking around in this morning's attempt I noticed
> .git/description, containing
>
> Unnamed repository; edit this file 'description' to name the repository.
>
> No idea if this is shown anywhere or if there is any practical way to
BTW, while poking around in this morning's attempt I noticed
.git/description, containing
Unnamed repository; edit this file 'description' to name the repository.
No idea if this is shown anywhere or if there is any practical way to
change it once the repo's been published. Might be an idea to s
On 09/20/2010 08:05 PM, Magnus Hagander wrote:
On Mon, Sep 20, 2010 at 7:57 PM, Magnus Hagander wrote:
On Mon, Sep 20, 2010 at 19:49, Tom Lane wrote:
Magnus Hagander writes:
On Mon, Sep 20, 2010 at 19:34, Tom Lane wrote:
Please fix and re-run.
Uh, what the heck. I ran the exact same co
On Mon, Sep 20, 2010 at 20:07, Tom Lane wrote:
> Magnus Hagander writes:
>> debian applies a patch to change it.
>
> [ rolls eyes... ] Thank you, debian.
Indeed.
For the archives, that's DateFormat=old, not DateStyle. Oops.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.
Magnus Hagander writes:
> debian applies a patch to change it.
[ rolls eyes... ] Thank you, debian.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-ha
On Mon, Sep 20, 2010 at 7:57 PM, Magnus Hagander wrote:
> On Mon, Sep 20, 2010 at 19:49, Tom Lane wrote:
>> Magnus Hagander writes:
>>> On Mon, Sep 20, 2010 at 19:34, Tom Lane wrote:
Please fix and re-run.
>>
>>> Uh, what the heck. I ran the exact same command as last time.. Hmm:
>>> Stefa
Magnus Hagander writes:
> Correct, I'm in en_US. I'm trying a "cvs export" in "C" now to see
> exaclty what changes.
> Hmm
> Nope, doesn't seem to change. I just set my LANG=C, and ran a "cvs
> export". but it comes back with "-" in the dates, so it seems to not
> care about that.
I thought "cvs
On Mon, Sep 20, 2010 at 19:49, Tom Lane wrote:
> Magnus Hagander writes:
>> On Mon, Sep 20, 2010 at 19:34, Tom Lane wrote:
>>> Please fix and re-run.
>
>> Uh, what the heck. I ran the exact same command as last time.. Hmm:
>> Stefan rbeooted the machine in between, I wonder if that changed
>> so
Magnus Hagander writes:
> On Mon, Sep 20, 2010 at 19:34, Tom Lane wrote:
>> Please fix and re-run.
> Uh, what the heck. I ran the exact same command as last time.. Hmm:
> Stefan rbeooted the machine in between, I wonder if that changed
> something.
I'm not sure we ever checked that. My compari
On Mon, Sep 20, 2010 at 19:34, Tom Lane wrote:
> Magnus Hagander writes:
>> Since there haven't been any commits in cvs during the day, the test
>> conversoin I created after lunch should be identical to a new one I'd
>> run now, so let's use that one :-)
>
> This is not even close to matching th
Magnus Hagander writes:
> Since there haven't been any commits in cvs during the day, the test
> conversoin I created after lunch should be identical to a new one I'd
> run now, so let's use that one :-)
This is not even close to matching the tarballs :-(. Seems to be a
locale problem: the diffs
Magnus Hagander wrote:
> Hi!
>
> CVS has been frozen, and all commit access locked out.
>
> Since there haven't been any commits in cvs during the day, the test
> conversoin I created after lunch should be identical to a new one I'd
> run now, so let's use that one :-)
>
> So I've moved it in pl
Hi!
CVS has been frozen, and all commit access locked out.
Since there haven't been any commits in cvs during the day, the test
conversoin I created after lunch should be identical to a new one I'd
run now, so let's use that one :-)
So I've moved it in place. It's on
http://git.postgresql.org/gi
53 matches
Mail list logo
