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.

Search Discussions

  • Bruce Momjian at Sep 20, 2010 at 5:27 pm

    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. +
  • Tom Lane at Sep 20, 2010 at 5:34 pm

    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 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
  • Magnus Hagander at Sep 20, 2010 at 5:43 pm

    On Mon, Sep 20, 2010 at 19:34, 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.
    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.
  • Tom Lane at Sep 20, 2010 at 5:49 pm

    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 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
  • Magnus Hagander at Sep 20, 2010 at 5:57 pm

    On Mon, Sep 20, 2010 at 19:49, Tom Lane wrote:
    Magnus Hagander <magnus@hagander.net> 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 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?
  • Tom Lane at Sep 20, 2010 at 6:00 pm

    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 export" removed keywords entirely ... try a checkout
    instead. Also, are you sure you don't have any LC_xxx variables set?

    regards, tom lane
  • Magnus Hagander at Sep 20, 2010 at 6:05 pm

    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 <magnus@hagander.net> 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 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?
    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.
  • Tom Lane at Sep 20, 2010 at 6:07 pm

    Magnus Hagander writes:
    debian applies a patch to change it.
    [ rolls eyes... ] Thank you, debian.

    regards, tom lane
  • Magnus Hagander at Sep 20, 2010 at 6:09 pm

    On Mon, Sep 20, 2010 at 20:07, Tom Lane 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.
  • Stefan Kaltenbrunner at Sep 20, 2010 at 6:15 pm

    On 09/20/2010 08:05 PM, Magnus Hagander wrote:
    On Mon, Sep 20, 2010 at 7:57 PM, Magnus Haganderwrote:
    On Mon, Sep 20, 2010 at 19:49, Tom Lanewrote:
    Magnus Hagander<magnus@hagander.net> writes:
    On Mon, Sep 20, 2010 at 19:34, Tom Lanewrote:
    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?
    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
  • Tom Lane at Sep 20, 2010 at 6:21 pm

    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
    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
  • Stefan Kaltenbrunner at Sep 20, 2010 at 6:29 pm

    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
  • Tom Lane at Sep 20, 2010 at 6:34 pm

    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
    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
  • Stefan Kaltenbrunner at Sep 20, 2010 at 6:41 pm

    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 at Sep 20, 2010 at 7:06 pm

    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 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
  • Stefan Kaltenbrunner at Sep 20, 2010 at 7:24 pm

    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 kflag in 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
  • Tom Lane at Sep 20, 2010 at 6:15 pm
    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
  • Andres Freund at Sep 20, 2010 at 6:17 pm

    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
  • Tom Lane at Sep 20, 2010 at 6:23 pm

    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 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
  • Andres Freund at Sep 20, 2010 at 6:26 pm

    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
  • Magnus Hagander at Sep 20, 2010 at 6:19 pm

    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
    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)
  • Tom Lane at Sep 20, 2010 at 6:25 pm

    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 locally initialized repo, or on
    the clone?
    That's what I found in the result of
    git 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
  • Magnus Hagander at Sep 20, 2010 at 8:11 pm

    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 <magnus@hagander.net> 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 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?
    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.
  • Tom Lane at Sep 21, 2010 at 3:38 am

    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 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
  • Magnus Hagander at Sep 21, 2010 at 10:46 am

    On Tue, Sep 21, 2010 at 05:38, Tom Lane 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.
  • Tom Lane at Sep 21, 2010 at 4:31 pm

    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 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
  • Robert Haas at Sep 21, 2010 at 4:38 pm

    On Tue, Sep 21, 2010 at 12:31 PM, Tom Lane wrote:
    Magnus Hagander <magnus@hagander.net> 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 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
  • Tom Lane at Sep 21, 2010 at 4:47 pm

    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 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
  • Magnus Hagander at Sep 21, 2010 at 4:51 pm

    On Tue, Sep 21, 2010 at 18:47, Tom Lane wrote:
    Robert Haas <robertmhaas@gmail.com> 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 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...
  • Tom Lane at Sep 21, 2010 at 4:55 pm

    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 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
  • Tom Lane at Sep 21, 2010 at 4:45 pm

    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.
  • Abhijit Menon-Sen at Sep 21, 2010 at 7:24 pm

    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
  • Bruce Momjian at Sep 20, 2010 at 6:48 pm

    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. +
  • Tom Lane at Sep 20, 2010 at 7:09 pm

    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/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
  • Peter Eisentraut at Sep 20, 2010 at 7:20 pm

    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?
  • Tom Lane at Sep 20, 2010 at 7:30 pm

    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 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
  • Bruce Momjian at Sep 20, 2010 at 7:57 pm

    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. +
  • Alvaro Herrera at Sep 21, 2010 at 5:32 pm

    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
  • Heikki Linnakangas at Sep 21, 2010 at 5:40 pm

    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
  • Robert Haas at Sep 21, 2010 at 5:43 pm

    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://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
  • Tom Lane at Sep 21, 2010 at 6:10 pm

    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 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? If so, what are they
    accomplishing exactly? I don't think I've entirely internalized what
    that command does.

    regards, tom lane
  • Heikki Linnakangas at Sep 21, 2010 at 6:17 pm

    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
  • Andrew Dunstan at Sep 21, 2010 at 6:30 pm

    On 09/21/2010 02:10 PM, Tom Lane wrote:
    Robert Haas<robertmhaas@gmail.com> 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 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? If so, what are they
    accomplishing exactly? I don't think I've entirely internalized what
    that command does.

    What I'm planning (unless someone convinces me it's a really bad idea)
    doesn't quite match any of the patterns on the wiki.

    It's kinda like this:

    git clone --mirrorssh://git@gitmaster.postgresql.org/postgresql.git
    git clone postgresql.git pg_rel9_0
    cd pg_rel9_0
    git checkout REL9_0_STABLE
    git remote set-url --push originssh://git@gitmaster.postgresql.org/postgresql.git


    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 push back to the remote
    master. ("git remote set-url --push" is a relatively recent addition to
    the ever changing git landscape.)

    cheers

    andrew
  • Alvaro Herrera at Sep 22, 2010 at 8:05 pm

    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
  • Aidan Van Dyk at Sep 22, 2010 at 8:20 pm

    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 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.
  • Alvaro Herrera at Sep 22, 2010 at 8:48 pm

    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 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
  • Alvaro Herrera at Sep 22, 2010 at 8:57 pm

    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
  • Alvaro Herrera at Sep 22, 2010 at 10:13 pm

    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
  • Robert Haas at Sep 22, 2010 at 8:36 pm

    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 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
  • Tom Lane at Sep 22, 2010 at 8:55 pm

    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
    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

Related Discussions

People

Translate

site design / logo © 2022 Grokbase