Thread: Git conversion status
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/gitweb?p=postgresql-migration.git. Git access available at git://git.postgresql.org/git/postgresql-migration.git. Committers can (and should! please test!) clone from git clone ssh://git@gitmaster.postgresql.org/postgresql.git. Please do *NOT* commit or push anything to this repository yet though: The repo is there - all the scripts to manage it are *not*. So don't commit until I confirm that it is. But please clone and verify the stuff we have now. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
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 place. It's on > http://git.postgresql.org/gitweb?p=postgresql-migration.git. Git > access available at > git://git.postgresql.org/git/postgresql-migration.git. > > Committers can (and should! please test!) clone from git clone > ssh://git@gitmaster.postgresql.org/postgresql.git. > > Please do *NOT* commit or push anything to this repository yet though: > The repo is there - all the scripts to manage it are *not*. So don't > commit until I confirm that it is. > > But please clone and verify the stuff we have now. Git clone worked just fine. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
Magnus Hagander <magnus@hagander.net> 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 look like
1c1
< /* $PostgreSQL: pgsql/contrib/citext/citext.sql.in,v 1.3 2008/09/05 18:25:16 tgl Exp $ */
---
> /* $PostgreSQL: pgsql/contrib/citext/citext.sql.in,v 1.3 2008-09-05 18:25:16 tgl Exp $ */
Please fix and re-run.
regards, tom lane
On Mon, Sep 20, 2010 at 19:34, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Magnus Hagander <magnus@hagander.net> 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 look like > > 1c1 > < /* $PostgreSQL: pgsql/contrib/citext/citext.sql.in,v 1.3 2008/09/05 18:25:16 tgl Exp $ */ > --- >> /* $PostgreSQL: pgsql/contrib/citext/citext.sql.in,v 1.3 2008-09-05 18:25:16 tgl Exp $ */ > > 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. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
Magnus Hagander <magnus@hagander.net> writes:
> On Mon, Sep 20, 2010 at 19:34, Tom Lane <tgl@sss.pgh.pa.us> 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 comparisons against the tarballs
were done from my own run of the conversion script. I'm using C locale
here, probably you aren't?
regards, tom lane
On Mon, Sep 20, 2010 at 19:49, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Magnus Hagander <magnus@hagander.net> writes:
>> On Mon, Sep 20, 2010 at 19:34, Tom Lane <tgl@sss.pgh.pa.us> 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 comparisons against the tarballs
> were done from my own run of the conversion script. I'm using C locale
> here, probably you aren't?
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.
("locale" clearly shows it's changed everything to C though)
Is there a cvs setting for this somewhere that you know of?
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
Magnus Hagander <magnus@hagander.net> 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 export" removed keywords entirely ... try a checkout
instead. Also, are you sure you don't have any LC_xxx variables set?
regards, tom lane
On Mon, Sep 20, 2010 at 7:57 PM, Magnus Hagander <magnus@hagander.net> wrote:
> On Mon, Sep 20, 2010 at 19:49, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Magnus Hagander <magnus@hagander.net> writes:
>>> On Mon, Sep 20, 2010 at 19:34, Tom Lane <tgl@sss.pgh.pa.us> 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 comparisons against the tarballs
>> were done from my own run of the conversion script. I'm using C locale
>> here, probably you aren't?
>
> 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,
soit seems to not care about that.
>
> ("locale" clearly shows it's changed everything to C though)
>
> Is there a cvs setting for this somewhere that you know of?
Think I found it.
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.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
Magnus Hagander <magnus@hagander.net> writes:
> debian applies a patch to change it.
[ rolls eyes... ] Thank you, debian.
regards, tom lane
On Mon, Sep 20, 2010 at 20:07, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Magnus Hagander <magnus@hagander.net> 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.redpill-linpro.com/
On 09/20/2010 08:05 PM, Magnus Hagander wrote:
> On Mon, Sep 20, 2010 at 7:57 PM, Magnus Hagander<magnus@hagander.net> wrote:
>> On Mon, Sep 20, 2010 at 19:49, Tom Lane<tgl@sss.pgh.pa.us> wrote:
>>> Magnus Hagander<magnus@hagander.net> writes:
>>>> On Mon, Sep 20, 2010 at 19:34, Tom Lane<tgl@sss.pgh.pa.us> 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 comparisons against the tarballs
>>> were done from my own run of the conversion script. I'm using C locale
>>> here, probably you aren't?
>>
>> 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,
soit seems to not care about that.
>>
>> ("locale" clearly shows it's changed everything to C though)
>>
>> Is there a cvs setting for this somewhere that you know of?
>
> Think I found it.
>
> 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
debian applied a patch to provide the old output for backwards
compatibility...
Stefan
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 stick
something in there.
regards, tom lane
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 > change it once the repo's been published. Might be an idea to stick > something in there. Its mostly used for display in gitweb and can be changed anytime. Andres
On Mon, Sep 20, 2010 at 20:15, Tom Lane <tgl@sss.pgh.pa.us> 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 > change it once the repo's been published. Might be an idea to stick > something in there. That's, AFAIK, only used for gitweb. That said, where was it set to that? A locally initialized repo, or on the clone? Because I changed it in the repository before I published it I think (i now deleted the whole repo to make room for the new conversion, so i can't doublecheck that :D) -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
Stefan Kaltenbrunner <stefan@kaltenbrunner.cc> 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
> debian applied a patch to provide the old output for backwards
> compatibility...
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.
regards, tom lane
Andres Freund <andres@anarazel.de> 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 if there is any practical way to
>> change it once the repo's been published. Might be an idea to stick
>> something in there.
> Its mostly used for display in gitweb and can be changed anytime.
Hm, I might've misinterpreted its semantics. Is that file copied by
"git clone", or is it something that's unique to each physical
repository?
regards, tom lane
Magnus Hagander <magnus@hagander.net> writes:
> On Mon, Sep 20, 2010 at 20:15, Tom Lane <tgl@sss.pgh.pa.us> 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 locally initialized repo, or on
> the clone?
That's what I found in the result ofgit clone ssh://git@gitmaster.postgresql.org/postgresql.git
If git clone isn't meant to copy it, then this is a non-issue.
regards, tom lane
On Monday 20 September 2010 20:22:55 Tom Lane wrote: > Andres Freund <andres@anarazel.de> 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 if there is any practical way to > >> change it once the repo's been published. Might be an idea to stick > >> something in there. > > > > Its mostly used for display in gitweb and can be changed anytime. > > Hm, I might've misinterpreted its semantics. Is that file copied by > "git clone", or is it something that's unique to each physical > repository? Unique to each "physical repository" (like everything in .git - unless you count the cloned 'objects'). Andres
On 09/20/2010 08:21 PM, Tom Lane wrote: > Stefan Kaltenbrunner<stefan@kaltenbrunner.cc> 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 >> debian applied a patch to provide the old output for backwards >> compatibility... > > 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. not sure - if I read the CVS changelog the "new style" output only triggers if both the server AND the client are > 1.12.x (for some value of x on both). As far as I know magnus is using a debian based CVS server for his testing so that would certainly be 1.12.x - are you too? Stefan
Stefan Kaltenbrunner <stefan@kaltenbrunner.cc> 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
> testing so that would certainly be 1.12.x - are you too?
No server anywhere: I'm reading from a local repository which is a
tarball copy of the one on cvs.postgresql.org. 1.12.13 is the only
version in question. (I believe Magnus is not using a server either;
the cvs2git documentation says that it will only work from a local repo,
and even if that's not true I shudder to think how long it would take
over a network.)
regards, tom lane
On 09/20/2010 08:33 PM, Tom Lane wrote: > Stefan Kaltenbrunner<stefan@kaltenbrunner.cc> 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 >> testing so that would certainly be 1.12.x - are you too? > > No server anywhere: I'm reading from a local repository which is a > tarball copy of the one on cvs.postgresql.org. 1.12.13 is the only > version in question. (I believe Magnus is not using a server either; > the cvs2git documentation says that it will only work from a local repo, > and even if that's not true I shudder to think how long it would take > over a network.) 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... Stefan
Tom Lane wrote: > Magnus Hagander <magnus@hagander.net> 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 look like > > 1c1 > < /* $PostgreSQL: pgsql/contrib/citext/citext.sql.in,v 1.3 2008/09/05 18:25:16 tgl Exp $ */ > --- > > /* $PostgreSQL: pgsql/contrib/citext/citext.sql.in,v 1.3 2008-09-05 18:25:16 tgl Exp $ */ > > Please fix and re-run. As a curiosity, I do prefer the dashed dates. I have had a number of cases where I have to change dashes to slashes when passing ISO dates as parameters to CVS. Shame they improve it just as we are leaving CVS. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
Stefan Kaltenbrunner <stefan@kaltenbrunner.cc> 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 the output of "cvs log". It doesn't say anything one way or the other about what gets put into $Header$ keyword expansions. A look into the 1.12.13 source code says that dates in keywords are always printed with this: sprintf (buf, "%04d/%02d/%02d %02d:%02d:%02d", year, mon, mday, hour, min, sec); (see printable_date in src/rcs.c). So I'm still of the opinion that debian fixed that which wasn't broken. I tried searching the nongnu archives and found this: http://lists.nongnu.org/archive/html/info-cvs/2004-03/msg00359.html which leads me to think that the upstream developers considered and ultimately rejected moving to ISO style in keyword expansion. Probably the debian maintainer decided he knew better and changed it anyway; there seems to be a lot of that going around among debian packagers. regards, tom lane
Bruce Momjian <bruce@momjian.us> 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/citext/citext.sql.in,v 1.3 2008-09-05 18:25:16 tgl Exp $ */
> As a curiosity, I do prefer the dashed dates. I have had a number of
> cases where I have to change dashes to slashes when passing ISO dates as
> parameters to CVS. Shame they improve it just as we are leaving CVS.
Yeah. It appears that this was prompted by a desire to match ISO style
going forward. 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 tarballs.
regards, tom lane
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 tarballs. Stupid question: Why don't you get rid of the key words beforehand?
On 09/20/2010 09:06 PM, Tom Lane wrote: > Stefan Kaltenbrunner<stefan@kaltenbrunner.cc> 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 the output of "cvs log". It doesn't say > anything one way or the other about what gets put into $Header$ keyword > expansions. A look into the 1.12.13 source code says that dates in > keywords are always printed with this: > > sprintf (buf, "%04d/%02d/%02d %02d:%02d:%02d", year, mon, mday, > hour, min, sec); > > (see printable_date in src/rcs.c). So I'm still of the opinion that > debian fixed that which wasn't broken. I tried searching the nongnu > archives and found this: > > http://lists.nongnu.org/archive/html/info-cvs/2004-03/msg00359.html > > which leads me to think that the upstream developers considered and > ultimately rejected moving to ISO style in keyword expansion. Probably > the debian maintainer decided he knew better and changed it anyway; > there seems to be a lot of that going around among debian packagers. wow - now that I look closer it seems you are right... The patch in debian against the upstream package (see: http://ftp.de.debian.org/debian/pool/main/c/cvs/cvs_1.12.13-12.diff.gz) has this hunk: --- cvs-1.12.13-old/src/rcs.c 2006-02-26 23:03:04.000000000 +0800 +++ cvs-1.12.13/src/rcs.c 2006-02-26 23:03:05.000000000 +0800 @@ -33,6 +33,8 @@ # endif #endif +int datesep = '-'; + /* The RCS -k options, and a set of enums that must match the array. These come first so that we can use enum kflagin function prototypes. */ @@ -3537,8 +3539,8 @@ &sec); if (year < 1900) year += 1900; - sprintf (buf, "%04d/%02d/%02d %02d:%02d:%02d", year, mon, mday, - hour, min, sec); + sprintf (buf, "%04d%c%02d%c%02d %02d:%02d:%02d", year, datesep, on, + datesep, mday, hour, min, sec); return xstrdup (buf); } so the broke that in early 2006 and nobody noticed so far... Stefan
Peter Eisentraut <peter_e@gmx.net> 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 match what's in the historical tarballs.
> Stupid question: Why don't you get rid of the key words beforehand?
That *definitely* wouldn't match the tarballs.
One of the base requirements we set at the beginning of the whole SCM
conversion discussion was that we be able to reproduce the historical
release tarballs as nearly as possible. Now, if there were some reason
that we couldn't match $PostgreSQL$ tags at all, I'd have grumbled and
accepted it. But we're 99.44% of the way there, and I don't see some
Debian maintainer's idea of how things ought to work as a reason for
not being 100% of the way there.
What I got the last time I did this locally, and expect to see when
we have the final conversion, is an exact match for every tarball
8.0.0 and later. Earlier than that we have discrepancies because
some files are now in Attic, and/or the cvsroot path moved around,
and/or the project's module name moved around. That sort of thing
I've resigned myself to just grumbling about. But if we can have an
exact match for everything from 8.0.0 forward, we should not give that
up for trivial reasons.
regards, tom lane
Tom Lane wrote: > Bruce Momjian <bruce@momjian.us> 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/citext/citext.sql.in,v 1.3 2008-09-05 18:25:16 tgl Exp $ */ > > > As a curiosity, I do prefer the dashed dates. I have had a number of > > cases where I have to change dashes to slashes when passing ISO dates as > > parameters to CVS. Shame they improve it just as we are leaving CVS. > > Yeah. It appears that this was prompted by a desire to match ISO style > going forward. 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 tarballs. Agreed, no question. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
On Mon, Sep 20, 2010 at 20:05, Magnus Hagander <magnus@hagander.net> wrote:
> On Mon, Sep 20, 2010 at 7:57 PM, Magnus Hagander <magnus@hagander.net> wrote:
>> On Mon, Sep 20, 2010 at 19:49, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> Magnus Hagander <magnus@hagander.net> writes:
>>>> On Mon, Sep 20, 2010 at 19:34, Tom Lane <tgl@sss.pgh.pa.us> 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 comparisons against the tarballs
>>> were done from my own run of the conversion script. I'm using C locale
>>> here, probably you aren't?
>>
>> 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,
soit seems to not care about that.
>>
>> ("locale" clearly shows it's changed everything to C though)
>>
>> Is there a cvs setting for this somewhere that you know of?
>
> Think I found it.
>
> 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.
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.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
Magnus Hagander <magnus@hagander.net> 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 version is good: it passes comparisons against all the
historical tarballs I have, as well as against my checked-out copies of
branch tips. History looks sane as best I can tell, too. I'm ready
to sign off on this.
NOTE: Magnus told me earlier that the new repository isn't ready to
accept commits, so committers please hold your fire till he gives
the all-clear. It looks okay to clone this and start working locally,
though.
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 the repo once it's open for pushing.
regards, tom lane
git tag PG95-1_08 bf3473c468b1938f782fdcc208bd62c4b061daa3
# commit bf3473c468b1938f782fdcc208bd62c4b061daa3 refs/heads/Release_1_0_3
# Author: Marc G. Fournier <scrappy@hub.org>
# Date: Fri Oct 4 20:38:49 1996 +0000
git tag PG95-1_09 1b5e30e615eacae651a3cd12aa6b5c44d398b919
# commit 1b5e30e615eacae651a3cd12aa6b5c44d398b919 refs/heads/Release_1_0_3
# Author: Marc G. Fournier <scrappy@hub.org>
# Date: Thu Oct 31 20:25:56 1996 +0000
git tag REL6_1 0acf9c9b28433120ca96a3a1c03222bfe45c8932
# commit 0acf9c9b28433120ca96a3a1c03222bfe45c8932 refs/tags/release-6-3
# Author: Bruce Momjian <bruce@momjian.us>
# Date: Fri Jun 13 14:08:48 1997 +0000
git tag REL6_1_1 b6d983559a2d2a6bd0b03b7b7f59a63a4c3f4918
# commit b6d983559a2d2a6bd0b03b7b7f59a63a4c3f4918 refs/tags/release-6-3
# Author: Bruce Momjian <bruce@momjian.us>
# Date: Mon Jul 21 22:29:41 1997 +0000
git tag REL6_2 d663f1c83944cf8934f549ff879b51364f1a60ad
# commit d663f1c83944cf8934f549ff879b51364f1a60ad refs/tags/release-6-3
# Author: Bruce Momjian <bruce@momjian.us>
# Date: Thu Oct 2 18:32:58 1997 +0000
git tag REL6_2_1 8a1a39c39079ebc26f1bb55ad1ed2a11c2d36045
# commit 8a1a39c39079ebc26f1bb55ad1ed2a11c2d36045 refs/tags/release-6-3
# Author: Bruce Momjian <bruce@momjian.us>
# Date: Sat Oct 18 16:59:06 1997 +0000
git tag REL6_3 b1c7c31e07b9284843d85bbe71a327a1ca13be63
# commit b1c7c31e07b9284843d85bbe71a327a1ca13be63 refs/tags/release-6-3
# Author: Marc G. Fournier <scrappy@hub.org>
# Date: Mon Mar 2 14:54:59 1998 +0000
git tag REL6_3_2 b542fa1a6e838d3e32857cdfbe8aeff940a91c74
# commit b542fa1a6e838d3e32857cdfbe8aeff940a91c74 refs/tags/REL6_5
# Author: Marc G. Fournier <scrappy@hub.org>
# Date: Sat Apr 18 18:32:44 1998 +0000
git tag REL6_4_2 3be6c6eb73922fb872a6251cb45cb89d8822744f
# commit 3be6c6eb73922fb872a6251cb45cb89d8822744f refs/heads/REL6_4
# Author: Bruce Momjian <bruce@momjian.us>
# Date: Sun Jan 3 06:50:17 1999 +0000
git tag REL6_5 275a1d054e72b35bfd98c9731e51b2961ab8dbf5
# commit 275a1d054e72b35bfd98c9731e51b2961ab8dbf5 refs/tags/REL6_5
# Author: Tom Lane <tgl@sss.pgh.pa.us>
# Date: Mon Jun 14 17:49:06 1999 +0000
git tag REL6_5_1 c7092a8e8fe67e556f5c7b2f1336453b2ebecbeb
# commit c7092a8e8fe67e556f5c7b2f1336453b2ebecbeb refs/heads/REL6_5_PATCHES
# Author: Bruce Momjian <bruce@momjian.us>
# Date: Mon Jul 19 05:08:23 1999 +0000
git tag REL6_5_2 d5d33e2ee453656d607ad6b1036f0091d29de25a
# commit d5d33e2ee453656d607ad6b1036f0091d29de25a refs/heads/REL6_5_PATCHES
# Author: Tom Lane <tgl@sss.pgh.pa.us>
# Date: Tue Sep 14 22:33:35 1999 +0000
git tag REL6_5_3 ef26b944b12ce52b14101512c39cf7a42ca970a6
# commit ef26b944b12ce52b14101512c39cf7a42ca970a6 refs/heads/REL6_5_PATCHES
# Author: Bruce Momjian <bruce@momjian.us>
# Date: Thu Nov 4 16:22:41 1999 +0000
git tag REL7_0_2 e261306b439e8286f8e8d7dcb6871c485df581c8
# commit e261306b439e8286f8e8d7dcb6871c485df581c8 refs/heads/REL7_0_PATCHES
# Author: Bruce Momjian <bruce@momjian.us>
# Date: Mon Jun 5 17:02:27 2000 +0000
git tag REL7_0_3 6835ca629877b9470f206cbea36c21aac9cdd493
# commit 6835ca629877b9470f206cbea36c21aac9cdd493 refs/heads/REL7_0_PATCHES
# Author: Marc G. Fournier <scrappy@hub.org>
# Date: Sun Nov 12 07:31:36 2000 +0000
git tag REL7_1 741604dd84dbbd58368a0206f73de259cb6718f4
# commit 741604dd84dbbd58368a0206f73de259cb6718f4 refs/tags/REL7_2_BETA1
# Author: Marc G. Fournier <scrappy@hub.org>
# Date: Fri Apr 13 21:21:33 2001 +0000
git tag REL7_1_1 ed6586063813cb4c9263254bb60b514cd12427e9
# commit ed6586063813cb4c9263254bb60b514cd12427e9 refs/tags/REL7_1_2
# Author: Marc G. Fournier <scrappy@hub.org>
# Date: Sat May 5 20:23:57 2001 +0000
git tag REL7_1_2 0b471cc338777b84f3510b124aeaa7de75572848
# commit 0b471cc338777b84f3510b124aeaa7de75572848 refs/heads/REL7_1_STABLE
# Author: Thomas G. Lockhart <lockhart@fourpalms.org>
# Date: Tue May 22 14:46:46 2001 +0000
git tag REL7_1_3 8c78169c4a766376317b2255572820dfcc52470e
# commit 8c78169c4a766376317b2255572820dfcc52470e refs/heads/REL7_1_STABLE
# Author: Marc G. Fournier <scrappy@hub.org>
# Date: Fri Aug 17 17:10:16 2001 +0000
git tag REL7_2_1 9de8b7b9f21ecda7bbf469db987221ff6b6e53cc
# commit 9de8b7b9f21ecda7bbf469db987221ff6b6e53cc refs/tags/REL7_2_3
# Author: Bruce Momjian <bruce@momjian.us>
# Date: Tue Mar 26 05:34:37 2002 +0000
git tag REL7_2_2 30ab8da488c3bbffc10115ec85e24e5855fc392d
# commit 30ab8da488c3bbffc10115ec85e24e5855fc392d refs/tags/REL7_2_3
# Author: Bruce Momjian <bruce@momjian.us>
# Date: Fri Aug 23 02:33:06 2002 +0000
git tag REL7_3 920c586f7045e955596786f14e100d10be040c32
# commit 920c586f7045e955596786f14e100d10be040c32 refs/tags/REL7_3_2
# Author: Tom Lane <tgl@sss.pgh.pa.us>
# Date: Wed Nov 27 23:21:20 2002 +0000
git tag REL7_3_1 a3feaba9aa60a35b811dce954a7b41dd169bf491
# commit a3feaba9aa60a35b811dce954a7b41dd169bf491 refs/tags/REL7_3_2
# Author: Tom Lane <tgl@sss.pgh.pa.us>
# Date: Sat Dec 21 01:07:21 2002 +0000
git tag REL7_3_3 abb2963a4c1de880da0b79317a9d6fbe168f23b7
# commit abb2963a4c1de880da0b79317a9d6fbe168f23b7 refs/tags/REL7_3_4
# Author: Tom Lane <tgl@sss.pgh.pa.us>
# Date: Thu May 22 20:38:56 2003 +0000
git tag Release_2_0_0 1960a3b96573ad1ec73cd50255edde29cc80df88
# commit 1960a3b96573ad1ec73cd50255edde29cc80df88 refs/tags/release-6-3
# Author: Marc G. Fournier <scrappy@hub.org>
# Date: Sat Aug 17 06:41:10 1996 +0000
git tag Release_2_0 bde34552a279a13a7980049455d6a79951cc5c5d
# commit bde34552a279a13a7980049455d6a79951cc5c5d refs/tags/release-6-3
# Author: Marc G. Fournier <scrappy@hub.org>
# Date: Wed Aug 14 16:44:51 1996 +0000
On Tue, Sep 21, 2010 at 05:38, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Magnus Hagander <magnus@hagander.net> 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 version is good: it passes comparisons against all the > historical tarballs I have, as well as against my checked-out copies of > branch tips. History looks sane as best I can tell, too. I'm ready > to sign off on this. Great. All my scripts and manual checks says it's fine too, so... > NOTE: Magnus told me earlier that the new repository isn't ready to > accept commits, so committers please hold your fire till he gives > the all-clear. It looks okay to clone this and start working locally, > though. It is now ready to go. The scripts shuold be in place, and I've verified both disallowed and allowed commits. Commit messages seem to be working. Do keep an eye out on things in the beginning, of course. And remember that if you do a commit, it might end up getting graylisted by the antispam servers the first time, so it might not show up right away. > 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 the repo once it's open for pushing. Go for it. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
Magnus Hagander <magnus@hagander.net> writes:
> On Tue, Sep 21, 2010 at 05:38, Tom Lane <tgl@sss.pgh.pa.us> 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 the repo once it's open for pushing.
> Go for it.
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?
regards, tom lane
On Tue, Sep 21, 2010 at 12:31 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Magnus Hagander <magnus@hagander.net> writes: >> On Tue, Sep 21, 2010 at 05:38, Tom Lane <tgl@sss.pgh.pa.us> 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 the repo once it's open for pushing. > >> Go for it. > > 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 pushing a whole boatload of tags at the same time is probably going to be an extremely rare event. And I am STRONGLY of the opinion that we do NOT want to collapse multiple *commits* into a single email, at least not unless we start merging or something. The scripts EDB uses internally do this and it is, at least IMO, just awful. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company
I wrote:
> Magnus Hagander <magnus@hagander.net> 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.
regards, tom lane
PS: this page is slightly amazing:
http://git.postgresql.org/gitweb?p=postgresql.git;a=tags
Fourteen years of project history. Wow.
Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, Sep 21, 2010 at 12:31 PM, Tom Lane <tgl@sss.pgh.pa.us> 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 pushing a whole
> boatload of tags at the same time is probably going to be an extremely
> rare event.
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.
regards, tom lane
On Tue, Sep 21, 2010 at 18:47, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> On Tue, Sep 21, 2010 at 12:31 PM, Tom Lane <tgl@sss.pgh.pa.us> 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 pushing a whole >> boatload of tags at the same time is probably going to be an extremely >> rare event. > > 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 into if it's possible to group the tags together if they come in a single push. I'm not entirely sure it's possible (I don't know if the commitmsg script gets called once in total or once for each), but I could look into it. However, I agree with Robert I doubt it's worth it. I definitely don't want to group the commits together, and then suddenly tags and commits are handled differently... -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
Magnus Hagander <magnus@hagander.net> writes:
> On Tue, Sep 21, 2010 at 18:47, Tom Lane <tgl@sss.pgh.pa.us> 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 into if it's possible to group the tags together if they
> come in a single push. I'm not entirely sure it's possible (I don't
> know if the commitmsg script gets called once in total or once for
> each), but I could look into it.
> However, I agree with Robert I doubt it's worth it.
Agreed. It's definitely not something to spend time on before the
update workflow becomes clear --- the case may never arise anyway.
regards, tom lane
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://git@gitmaster.postgresql.org/postgresql.git. > > Please do *NOT* commit or push anything to this repository yet though: > The repo is there - all the scripts to manage it are *not*. So don't > commit until I confirm that it is. > > But please clone and verify the stuff we have now. I tried to follow the instructions on the Wiki but they didn't work. The ones under the heading "Dependent Clone per Branch, Pushing and Pulling From a Local Repository" that is. 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 this message: $ git checkout REL9_0_STABLE error: pathspec 'REL9_0_STABLE' did not match any file(s) known to git. So I first need to checkout each branch on the "postgresql" clone (the one tracking the remote), and then do the local clone. So the instructions are: branches="REL9_0_STABLE REL8_4_STABLE REL8_3_STABLE REL8_2_STABLE REL8_1_STABLE REL8_0_STABLE REL7_4_STABLE" pushd postgresql/ for i in $branches; do git checkout $i; done popd for i in $branches; do git clone postgresql $i --branch $i; done and then set the config variables on each clone, as specified. -- Álvaro Herrera <alvherre@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support
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 this message: It clones all branches, but it only creates a local tracking branch for master automatically. The others you'll have to create manually: git branch REL9_0_STABLE origin/REL9_0_STABLE Try also "git branch -a", it is quite enlightening. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
On Tue, Sep 21, 2010 at 1:32 PM, Alvaro Herrera <alvherre@commandprompt.com> 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://git@gitmaster.postgresql.org/postgresql.git. >> >> Please do *NOT* commit or push anything to this repository yet though: >> The repo is there - all the scripts to manage it are *not*. So don't >> commit until I confirm that it is. >> >> But please clone and verify the stuff we have now. > > I tried to follow the instructions on the Wiki but they didn't work. > The ones under the heading "Dependent Clone per Branch, Pushing and > Pulling From a Local Repository" that is. > > 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 this message: > > $ git checkout REL9_0_STABLE > error: pathspec 'REL9_0_STABLE' did not match any file(s) known to git. Oops. I left out a step. Fixed. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company
Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, Sep 21, 2010 at 1:32 PM, Alvaro Herrera
> <alvherre@commandprompt.com> 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 workdirs" alternative are these recipes for
re-syncing your local checkouts:
git checkout REL9_0_STABLEgit pull
git checkout mastergit reset --hard origin/master
Are the git checkout steps really needed, considering each workdir would
normally be on its target branch all the time? If so, what are they
accomplishing exactly? I don't think I've entirely internalized what
that command does.
regards, tom lane
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 > git reset --hard origin/master > > Are the git checkout steps really needed, considering each workdir would > normally be on its target branch all the time? No, you're right, they're not really needed. Those steps were copy-pasted from the "Committing Using a Single Clone" recipe, and not adjusted. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
<br /><br /> On 09/21/2010 02:10 PM, Tom Lane wrote: <blockquote cite="mid:6392.1285092648@sss.pgh.pa.us"
type="cite"><prewrap="">Robert Haas <a class="moz-txt-link-rfc2396E"
href="mailto:robertmhaas@gmail.com"><robertmhaas@gmail.com></a>writes:
</pre><blockquote type="cite"><pre wrap="">On Tue, Sep 21, 2010 at 1:32 PM, Alvaro Herrera
<a class="moz-txt-link-rfc2396E" href="mailto:alvherre@commandprompt.com"><alvherre@commandprompt.com></a>
wrote:
</pre><blockquote type="cite"><pre wrap="">I tried to follow the instructions on the Wiki but they didn't work.
</pre></blockquote></blockquote><pre wrap="">
</pre><blockquote type="cite"><pre wrap="">Oops. I left out a step. Fixed.
</pre></blockquote><pre wrap="">
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_STABLEgit pull
git checkout mastergit reset --hard origin/master
Are the git checkout steps really needed, considering each workdir would
normally be on its target branch all the time? If so, what are they
accomplishing exactly? I don't think I've entirely internalized what
that command does.
</pre></blockquote><br /><br /> What I'm planning (unless someone convinces me it's a really bad idea) doesn't quite
matchany of the patterns on the wiki. <br /><br /> It's kinda like this:<br /><blockquote><pre>git clone --mirror <a
class="moz-txt-link-abbreviated"
href="mailto:ssh://git@gitmaster.postgresql.org/postgresql.git">ssh://git@gitmaster.postgresql.org/postgresql.git</a>
<spanclass="moz-txt-citetags">
</span>git clone postgresql.git pg_rel9_0 <span class="moz-txt-citetags">
</span>cd pg_rel9_0
<span class="moz-txt-citetags"></span>git checkout REL9_0_STABLE
<span class="moz-txt-citetags"></span>git remote set-url --push origin <a class="moz-txt-link-abbreviated"
href="mailto:ssh://git@gitmaster.postgresql.org/postgresql.git">ssh://git@gitmaster.postgresql.org/postgresql.git</a></pre></blockquote><br
/>with a cron job to do a "git fetch -q" fairly frequently on the mirror. That way I'll pull from the local mirror but
pushback to the remote master. ("git remote set-url --push" is a relatively recent addition to the ever changing git
landscape.)<br/><br /> cheers<br /><br /> andrew<br />
At 2010-09-21 12:45:20 -0400, tgl@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 safely delete the tag from the upstream repository with: git push origin :refs/tags/release-6-3 New clones of the repository will not see that tag, but existing clones will continue to have it. Anyone who runs "git push --tags" from such a clone without deleting the tag manually (git tag -d release-6-3) will, however, restore the tag upstream. I'd say it's not worth the bother. -- ams
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 know should be pulled in. For example: $ cd postgresql/ $ git fetch remote: Counting objects: 219, done. remote: Compressing objects: 100% (88/88), done. remote: Total 89 (delta 77), reused 0 (delta 0) Unpacking objects: 100% (89/89), done. From ssh://gitmaster.postgresql.org/postgresql 6b4453f..da907fd REL7_4_STABLE -> origin/REL7_4_STABLE 92458c2..da49d16 REL8_0_STABLE -> origin/REL8_0_STABLE 3fb50a7..706a580 REL8_1_STABLE -> origin/REL8_1_STABLE adbe80f..c206794 REL8_2_STABLE -> origin/REL8_2_STABLE c39a381..60591cd REL8_3_STABLE -> origin/REL8_3_STABLE 35b2f93..2792c82 REL8_4_STABLE -> origin/REL8_4_STABLE bbf84ac..f23bc1e REL9_0_STABLE -> origin/REL9_0_STABLE 726f9dd..6c137da master -> origin/master $ cd ../REL9_0_STABLE $ git pull Current branch REL9_0_STABLE is up to date. But I know this is wrong: $ git log -1 commit a6923594114601b4aaaf0cfd82eb5088af837664 Author: Magnus Hagander <magnus@hagander.net> Date: Wed Sep 22 12:57:06 2010 +0200 Convert cvsignore to gitignore, and add .gitignore for build targets. $ cd ../postgresql $ git checkout REL9_0_STABLE Checking out files: 100% (2415/2415), done. Switched to branch 'REL9_0_STABLE' Your branch is behind 'origin/REL9_0_STABLE' by 2 commits, and can be fast-forwarded. $ git pull [ lotsa output ] $ git log -1 commit f23bc1e8a42cab50c204bbab837f95cbc2353311 Author: Magnus Hagander <magnus@hagander.net> Date: Wed Sep 22 21:49:07 2010 +0200 Add gitignore files for ecpg regression tests. Backpatch to 8.2 as that's how far the structure looks the same. 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 out. -- Álvaro Herrera <alvherre@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support
On Wed, Sep 22, 2010 at 4:04 PM, Alvaro Herrera <alvherre@commandprompt.com> 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 out. What I think has happened is that you have a master clone, and you've cloned *that* to your "working" repositories, right? And you "pull" in your master repository, and that updates the *remote* tracking branches. But it doesn't automatically "merge" (or what you want, replace) the *local* branches of the master repository.Until you do so. 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 repository just be a bare mirror repo, not a full-fledged-with-working-directory repository. If it's just a mirror of the remote, it doesn't have the distinction between "remote" branches and "local" branches, and your local working clones of it will see exactly what it's fetched from the remote.
On Wed, Sep 22, 2010 at 4:04 PM, Alvaro Herrera <alvherre@commandprompt.com> 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 clones, it says > it's up to date even when there are commits that I know should be pulled > in. > > For example: > > $ cd postgresql/ > $ git fetch > remote: Counting objects: 219, done. > remote: Compressing objects: 100% (88/88), done. > remote: Total 89 (delta 77), reused 0 (delta 0) > Unpacking objects: 100% (89/89), done. > From ssh://gitmaster.postgresql.org/postgresql > 6b4453f..da907fd REL7_4_STABLE -> origin/REL7_4_STABLE > 92458c2..da49d16 REL8_0_STABLE -> origin/REL8_0_STABLE > 3fb50a7..706a580 REL8_1_STABLE -> origin/REL8_1_STABLE > adbe80f..c206794 REL8_2_STABLE -> origin/REL8_2_STABLE > c39a381..60591cd REL8_3_STABLE -> origin/REL8_3_STABLE > 35b2f93..2792c82 REL8_4_STABLE -> origin/REL8_4_STABLE > bbf84ac..f23bc1e REL9_0_STABLE -> origin/REL9_0_STABLE > 726f9dd..6c137da master -> origin/master > > $ cd ../REL9_0_STABLE > $ git pull > Current branch REL9_0_STABLE is up to date. > > But I know this is wrong: > > $ git log -1 > commit a6923594114601b4aaaf0cfd82eb5088af837664 > Author: Magnus Hagander <magnus@hagander.net> > Date: Wed Sep 22 12:57:06 2010 +0200 > > Convert cvsignore to gitignore, and add .gitignore for build targets. > > $ cd ../postgresql > $ git checkout REL9_0_STABLE > Checking out files: 100% (2415/2415), done. > Switched to branch 'REL9_0_STABLE' > Your branch is behind 'origin/REL9_0_STABLE' by 2 commits, and can be fast-forwarded. > $ git pull > [ lotsa output ] > > $ git log -1 > commit f23bc1e8a42cab50c204bbab837f95cbc2353311 > Author: Magnus Hagander <magnus@hagander.net> > Date: Wed Sep 22 21:49:07 2010 +0200 > > Add gitignore files for ecpg regression tests. > > Backpatch to 8.2 as that's how far the structure looks the same. > > > > 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 out. Ah, crap. You're right. Sucktastic. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company
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 > <alvherre@commandprompt.com> 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 out. > > What I think has happened is that you have a master clone, and you've > cloned *that* to your "working" repositories, right? Yep. This is in accord with the instructions written in this section: http://wiki.postgresql.org/wiki/Committing_with_Git#Dependent_Clone_per_Branch.2C_Pushing_and_Pulling_From_a_Local_Repository > And you "pull" in your master repository, and that updates the > *remote* tracking branches. But it doesn't automatically "merge" (or > what you want, replace) the *local* branches of the master repository. > Until you do so. Right. > 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 > repository just be a bare mirror repo, not a > full-fledged-with-working-directory repository. If it's just a mirror > of the remote, it doesn't have the distinction between "remote" > branches and "local" branches, and your local working clones of it > will see exactly what it's fetched from the remote. Yeah, I think this is what I want. I'll try to see how to make that work. -- Álvaro Herrera <alvherre@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Robert Haas <robertmhaas@gmail.com> writes:
> On Wed, Sep 22, 2010 at 4:04 PM, Alvaro Herrera
> <alvherre@commandprompt.com> 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 out.
> Ah, crap. You're right. Sucktastic.
As far as I can tell so far, the multiple-workdir setup dominates all
the others in terms of minimizing the amount of "git pull" monkeywork.
You still have to remember to do that (or some equivalent) in each
workdir to update that workdir, but that's no worse than with multiple
CVS checkout directories. And the amount of network overhead is a LOT
less than with multiple CVS checkouts.
(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 how much better this is
than CVS already, I won't miss whatever savings that might offer.)
regards, tom lane
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 > > repository just be a bare mirror repo, not a > > full-fledged-with-working-directory repository. If it's just a mirror > > of the remote, it doesn't have the distinction between "remote" > > branches and "local" branches, and your local working clones of it > > will see exactly what it's fetched from the remote. > > Yeah, I think this is what I want. I'll try to see how to make that work. Apparently the only difference is that the initial clone needs to be done with --bare:git clone --bare ssh://git@gitmaster.postgresql.org/postgresql.git and then the second line (which Robert added yesterday) is not necessary. Now I only need to wait for another commit to come in to test that fetch/pull work ... -- Álvaro Herrera <alvherre@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support
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 how much better this is > than CVS already, I won't miss whatever savings that might offer.) Oh, yes, the network saving is enormous. What I suggested is much more economical of disk space, though (it's the recommended way to set up the buildfarm for that reason). But maybe that doesn't matter too much to you. cheers andrew
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://git@gitmaster.postgresql.org/postgresql.git Okay, it works with --bare --mirror. I'm going to update the wiki with this. -- Álvaro Herrera <alvherre@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Tom Lane wrote: > Robert Haas <robertmhaas@gmail.com> writes: > > On Wed, Sep 22, 2010 at 4:04 PM, Alvaro Herrera > > <alvherre@commandprompt.com> 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 out. > > > Ah, crap. You're right. Sucktastic. > > As far as I can tell so far, the multiple-workdir setup dominates all > the others in terms of minimizing the amount of "git pull" monkeywork. Yes, that is what I am using too. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +