On Sun, Sep 26, 2010 at 1:51 AM, Tom Lane wrote:
Still more tweaking of git_changelog.

1. Don't assume there's only one candidate match; check them all and use the
one with the closest timestamp.  Avoids funny output when someone makes
several successive commits with the same log message, as certain people
have been known to do.

2. When the same commit (with the same SHA1) is reachable from multiple
branch tips, don't report it for all the branches; instead report it only
for the first such branch.  Given our development practices, this case
arises only for commits that occurred before a given branch split off from
master.  The original coding blamed old commits on *all* the branches,
which isn't terribly useful; the new coding blames such a commit only on
master.
Uhm, could you stop massively changing the behavior of this script
with no discussion at all? I happen to think that this is a
distinctly bad idea. It defeats one of the major use cases of the
original script, which is being able to easily figure out which
branches a certain commit is in. If you want to have an option for
this behavior, fine, but please do not presume that everyone wants the
same thing as you (since that is evidently not the case) or that you
are the only person who is using it (if that were so, it should be
stored in your personal workspace, rather than our community
repository).

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

Search Discussions

  • Tom Lane at Sep 26, 2010 at 4:08 pm

    Robert Haas writes:
    On Sun, Sep 26, 2010 at 1:51 AM, Tom Lane wrote:
    Still more tweaking of git_changelog.
    Uhm, could you stop massively changing the behavior of this script
    with no discussion at all?
    Uh, there was no discussion of the original behavior of the script
    either.
    I happen to think that this is a
    distinctly bad idea. It defeats one of the major use cases of the
    original script, which is being able to easily figure out which
    branches a certain commit is in.
    Hm? As far as I can tell, this fixes that not breaks it. The problem
    I was seeing was that commits would be attributed to a branch when in
    fact they were made before the branch ever existed.
    If you want to have an option for
    this behavior, fine, but please do not presume that everyone wants the
    same thing as you (since that is evidently not the case) or that you
    are the only person who is using it (if that were so, it should be
    stored in your personal workspace, rather than our community
    repository).
    I was under the impression that the purpose of the script was to replace
    cvs2cl and do approximately what cvs2cl did. If you have another
    use-case then please explain what it is and why this change is bad
    for it.

    regards, tom lane
  • Robert Haas at Sep 26, 2010 at 4:25 pm

    On Sun, Sep 26, 2010 at 12:08 PM, Tom Lane wrote:
    Robert Haas <robertmhaas@gmail.com> writes:
    On Sun, Sep 26, 2010 at 1:51 AM, Tom Lane wrote:
    Still more tweaking of git_changelog.
    Uhm, could you stop massively changing the behavior of this script
    with no discussion at all?
    Uh, there was no discussion of the original behavior of the script
    either.
    It was posted to the list weeks before it was committed and it was
    discussed by multiple people at that time. We didn't debate every
    detail of the behavior but there was certainly ample space for public
    comment.
    I happen to think that this is a
    distinctly bad idea.  It defeats one of the major use cases of the
    original script, which is being able to easily figure out which
    branches a certain commit is in.
    Hm?  As far as I can tell, this fixes that not breaks it.  The problem
    I was seeing was that commits would be attributed to a branch when in
    fact they were made before the branch ever existed.
    But the commits are still on any subsequently-created branches.
    Frequently, I'm trying to figure out the first release that contains
    some particular change. Say, tablespaces. So I go back and look
    through the git log and find the commit. And here it is:
    2467394ee1566e82d0314d12a0d1c0a5670a28c9.

    Now I want to know which branches contain that commit. With the old
    coding, I can just run this script, and it'll tell me all the branches
    REL8_0_STABLE and higher have that commit. If the abbreviated SHA1
    hashes are the same, I know that the commit was actually done before
    the branch points for those releases. If they're different, I know
    that the commit was back-patched into those branches. With your
    changes, all I get is:

    Author: Tom Lane <tgl@sss.pgh.pa.us>
    Branch: master [2467394ee] 2004-06-18 06:14:31 +0000

    ...which is much less useful, at least given that I don't have the
    dates of all the branch points memorized.
    I was under the impression that the purpose of the script was to replace
    cvs2cl and do approximately what cvs2cl did.  If you have another
    use-case then please explain what it is and why this change is bad
    for it.
    See above.

    Thanks,

    --
    Robert Haas
    EnterpriseDB: http://www.enterprisedb.com
    The Enterprise Postgres Company
  • Tom Lane at Sep 26, 2010 at 4:42 pm

    Robert Haas writes:
    On Sun, Sep 26, 2010 at 12:08 PM, Tom Lane wrote:
    Hm?  As far as I can tell, this fixes that not breaks it.  The problem
    I was seeing was that commits would be attributed to a branch when in
    fact they were made before the branch ever existed.
    But the commits are still on any subsequently-created branches.
    Frequently, I'm trying to figure out the first release that contains
    some particular change. Say, tablespaces. So I go back and look
    through the git log and find the commit. And here it is:
    2467394ee1566e82d0314d12a0d1c0a5670a28c9.
    Now I want to know which branches contain that commit. With the old
    coding, I can just run this script, and it'll tell me all the branches
    REL8_0_STABLE and higher have that commit. If the abbreviated SHA1
    hashes are the same, I know that the commit was actually done before
    the branch points for those releases. If they're different, I know
    that the commit was back-patched into those branches.
    Well, all I can say is that I find that unnecessarily verbose, and
    that in ten years of working with cvs2cl I can't recall ever once
    wishing that it would behave that way.

    What I do often wish is that it were easier to tell which point-releases
    a given patch was applied between, ie, if it's on the 8.4 branch did it
    appear in 8.4.1, 8.4.2, etc. But neither of these behaviors is useful
    for that.

    If we could figure out how to show which major release a master-branch
    commit antedated, and which point release a back-branch commit
    antedated, I think we would have something that's actually significantly
    more useful for both purposes than either of these behaviors. It would
    show you what you want without having to make nonobvious deductions
    from comparisons of commit hashes, and it would also ease my main
    use-case which is "which point release did that get fixed in?"

    I've experimented with git log --all --source but it tends to make
    unhelpful choices of which tag to report; maybe the secret would be
    to limit the set of tags it chases from?

    regards, tom lane
  • Tom Lane at Sep 26, 2010 at 5:25 pm

    I wrote:
    If we could figure out how to show which major release a master-branch
    commit antedated, and which point release a back-branch commit
    antedated, I think we would have something that's actually significantly
    more useful for both purposes than either of these behaviors.
    I think we could get that behavior fairly easily by remembering the last
    tag matching one of the commits on a branch, as we chase the branch
    backwards. However, I'm not seeing a convenient way to extract the
    commit SHA1s pointed to by the available tags. git tag doesn't tell
    this and git show provides way too much information. Anybody know the
    right incantation for that?

    regards, tom lane
  • Robert Haas at Sep 26, 2010 at 5:29 pm

    On Sun, Sep 26, 2010 at 1:25 PM, Tom Lane wrote:
    I wrote:
    If we could figure out how to show which major release a master-branch
    commit antedated, and which point release a back-branch commit
    antedated, I think we would have something that's actually significantly
    more useful for both purposes than either of these behaviors.
    I think we could get that behavior fairly easily by remembering the last
    tag matching one of the commits on a branch, as we chase the branch
    backwards.  However, I'm not seeing a convenient way to extract the
    commit SHA1s pointed to by the available tags.  git tag doesn't tell
    this and git show provides way too much information.  Anybody know the
    right incantation for that?
    git rev-parse REL8_3_0

    But I still want an option for the original behavior. I have been
    using it extensively and I like it.

    --
    Robert Haas
    EnterpriseDB: http://www.enterprisedb.com
    The Enterprise Postgres Company
  • Tom Lane at Sep 26, 2010 at 6:08 pm

    Robert Haas writes:
    But I still want an option for the original behavior. I have been
    using it extensively and I like it.
    You really think this:

    Author: Tom Lane <tgl@sss.pgh.pa.us>
    Branch: master [872c1497f] 2005-05-24 18:02:31 +0000
    Branch: REL9_0_STABLE [872c1497f] 2005-05-24 18:02:31 +0000
    Branch: REL8_4_STABLE [872c1497f] 2005-05-24 18:02:31 +0000
    Branch: REL8_3_STABLE [872c1497f] 2005-05-24 18:02:31 +0000
    Branch: REL8_2_STABLE [872c1497f] 2005-05-24 18:02:31 +0000
    Branch: REL8_1_STABLE [872c1497f] 2005-05-24 18:02:31 +0000
    Branch: REL8_0_STABLE [a94ace079] 2005-05-24 18:02:55 +0000
    Branch: REL7_4_STABLE [0a7b3a364] 2005-05-24 18:03:24 +0000

    Previous fix for "x FULL JOIN y ON true" failed to handle the case
    where there was also a WHERE-clause restriction that applied to the
    join. The check on restrictlist == NIL is really unnecessary anyway,
    because select_mergejoin_clauses already checked for and complained
    about any unmergejoinable join clauses. So just take it out.

    is preferable to something like

    Author: Tom Lane <tgl@sss.pgh.pa.us>
    Branch: master Release: REL8_1 [872c1497f] 2005-05-24 18:02:31 +0000
    Branch: REL8_0_STABLE Release: REL8_0_4 [a94ace079] 2005-05-24 18:02:55 +0000
    Branch: REL7_4_STABLE Release: REL7_4_9 [0a7b3a364] 2005-05-24 18:03:24 +0000

    Previous fix for "x FULL JOIN y ON true" failed to handle the case
    where there was also a WHERE-clause restriction that applied to the
    join. The check on restrictlist == NIL is really unnecessary anyway,
    because select_mergejoin_clauses already checked for and complained
    about any unmergejoinable join clauses. So just take it out.

    ? It's not hard to offer an option for that, I guess, but I foresee an
    argument about what the default is going to be.

    regards, tom lane
  • Robert Haas at Sep 26, 2010 at 6:12 pm

    On Sun, Sep 26, 2010 at 2:07 PM, Tom Lane wrote:
    [Do you really want the behavior you said you wanted?] Yes.
    ?  It's not hard to offer an option for that, I guess, but I foresee an
    argument about what the default is going to be.
    If there's no clear consensus, I'm OK with the time-honored tie-break
    of "he who does the work...".

    --
    Robert Haas
    EnterpriseDB: http://www.enterprisedb.com
    The Enterprise Postgres Company
  • Tom Lane at Sep 26, 2010 at 7:27 pm

    Robert Haas writes:
    On Sun, Sep 26, 2010 at 2:07 PM, Tom Lane wrote:
    ?  It's not hard to offer an option for that, I guess, but I foresee an
    argument about what the default is going to be.
    If there's no clear consensus, I'm OK with the time-honored tie-break
    of "he who does the work...".
    How about

    Usage: git_changelog [--post-date/-p] [--since=SINCE]
    --post-date Show branches made after a commit occurred
    --since Print only commits dated since SINCE

    ? Got a better name for it?

    regards, tom lane
  • Dimitri Fontaine at Sep 27, 2010 at 8:04 am

    Tom Lane writes:
    Author: Tom Lane <tgl@sss.pgh.pa.us>
    Branch: master Release: REL8_1 [872c1497f] 2005-05-24 18:02:31 +0000
    Branch: REL8_0_STABLE Release: REL8_0_4 [a94ace079] 2005-05-24 18:02:55 +0000
    Branch: REL7_4_STABLE Release: REL7_4_9 [0a7b3a364] 2005-05-24 18:03:24 +0000

    Previous fix for "x FULL JOIN y ON true" failed to handle the case
    where there was also a WHERE-clause restriction that applied to the
    join. The check on restrictlist == NIL is really unnecessary anyway,
    because select_mergejoin_clauses already checked for and complained
    about any unmergejoinable join clauses. So just take it out.
    It's easy enough to find it on the website too, or to search for some
    other patch as I did this morning:

    http://git.postgresql.org/gitweb?p=postgresql.git;a=commit;h=872c1497f
    http://git.postgresql.org/gitweb?p=postgresql.git;a=commit;h=40608e7f949fb7e4025c0ddd5be01939adc79eec

    Having your proposed output in there would be awesome, because the use
    case of determining which releases contain the patch is a *huge* one of
    course --- and gitweb searches are easy, fast and convenient.

    Now I can't comment on the git_changelog tool chapter, so that's a
    little Off Topic, but still. Can we do something about the gitweb
    interface to include such a feature?

    Regards,
    --
    dim
  • Dimitri Fontaine at Sep 28, 2010 at 11:46 am

    Dimitri Fontaine writes:
    Tom Lane <tgl@sss.pgh.pa.us> writes:
    Author: Tom Lane <tgl@sss.pgh.pa.us>
    Branch: master Release: REL8_1 [872c1497f] 2005-05-24 18:02:31 +0000
    Branch: REL8_0_STABLE Release: REL8_0_4 [a94ace079] 2005-05-24 18:02:55 +0000
    Branch: REL7_4_STABLE Release: REL7_4_9 [0a7b3a364] 2005-05-24 18:03:24 +0000
    http://git.postgresql.org/gitweb?p=postgresql.git;a=commit;h=872c1497f
    http://git.postgresql.org/gitweb?p=postgresql.git;a=commit;h=40608e7f949fb7e4025c0ddd5be01939adc79eec

    Can we do something about the gitweb interface to include such a feature?
    Please?
    --
    dim
  • Tom Lane at Sep 26, 2010 at 7:24 pm

    I wrote:
    I think we could get that behavior fairly easily by remembering the last
    tag matching one of the commits on a branch, as we chase the branch
    backwards.
    I find that this works just fine for the branches, but not so well for
    master, because more often than not the initial RELx_y_z tag is applied
    on the release's branch and not on master. So for example commits on
    master appear to jump from REL7_2 development to REL8_0 development,
    because 7.3 and 7.4 have no release tag on the master branch.

    We could perhaps fix that if there were an inexpensive way to get the
    SHA1 of the master commit that each branch is sprouted from. However,
    I'm inclined to propose that we instead manually place a tag at each
    sprout point. Any thoughts about that? In particular, what should
    the naming convention for such tags be? I would have liked to use
    RELx_y, but that's out because before 8.0 we named the initial
    releases that way.

    regards, tom lane
  • Gurjeet Singh at Sep 26, 2010 at 7:45 pm

    On Sun, Sep 26, 2010 at 3:24 PM, Tom Lane wrote:

    We could perhaps fix that if there were an inexpensive way to get the
    SHA1 of the master commit that each branch is sprouted from. However,
    I'm inclined to propose that we instead manually place a tag at each
    sprout point. Any thoughts about that? In particular, what should
    the naming convention for such tags be? I would have liked to use
    RELx_y, but that's out because before 8.0 we named the initial
    releases that way.
    SPLITx_y, STAMPx_y, BRANCHx_y

    --
    gurjeet.singh
    @ EnterpriseDB - The Enterprise Postgres Company
    http://www.EnterpriseDB.com

    singh.gurjeet@{ gmail | yahoo }.com
    Twitter/Skype: singh_gurjeet

    Mail sent from my BlackLaptop device
  • Tom Lane at Sep 26, 2010 at 8:38 pm

    I wrote:
    We could perhaps fix that if there were an inexpensive way to get the
    SHA1 of the master commit that each branch is sprouted from. However,
    I'm inclined to propose that we instead manually place a tag at each
    sprout point.
    Hah, I have a plan. Let's just run git log for "master..RELx_y_STABLE"
    for each branch, rather than all the way back. Then we can identify the
    sprout point as the parent of the last emitted commit for the branch.
    The "post dated" or "double tagged" or whatever you call 'em branch
    annotations for earlier master commits can then be inserted by hand,
    rather than reverse-engineering them by matching author/message/etc.
    This should be both faster and more reliable than the current method.

    Note: if using --since then this method won't necessarily identify the
    sprout point: we might end up with the SHA1 of some commit on the
    branch. But it won't matter, because we won't be going back far enough
    on the master branch for there to be any commits that need to be
    double-tagged for that branch.

    A possible objection to this method is that it might be difficult to
    scale it up to cases where you were interested in branches sprouting off
    of maintenance branches, rather than only branches sprouted directly
    from master. But I find it hard to foresee caring about such cases.

    regards, tom lane
  • Robert Haas at Sep 26, 2010 at 9:11 pm

    On Sun, Sep 26, 2010 at 4:38 PM, Tom Lane wrote:
    I wrote:
    We could perhaps fix that if there were an inexpensive way to get the
    SHA1 of the master commit that each branch is sprouted from.  However,
    I'm inclined to propose that we instead manually place a tag at each
    sprout point.
    Hah, I have a plan.  Let's just run git log for "master..RELx_y_STABLE"
    for each branch, rather than all the way back.  Then we can identify the
    sprout point as the parent of the last emitted commit for the branch.
    The "post dated" or "double tagged" or whatever you call 'em branch
    annotations for earlier master commits can then be inserted by hand,
    rather than reverse-engineering them by matching author/message/etc.
    This should be both faster and more reliable than the current method.
    This doesn't seem more reliable to me in any way. Looking at the
    actual commit history must surely be more reliable than assuming you
    know what it is. I think what you should be doing is using git log
    --decorate and extracting the information from that as you go by.

    --
    Robert Haas
    EnterpriseDB: http://www.enterprisedb.com
    The Enterprise Postgres Company
  • Tom Lane at Sep 27, 2010 at 12:24 am

    Robert Haas writes:
    On Sun, Sep 26, 2010 at 4:38 PM, Tom Lane wrote:
    Hah, I have a plan.  Let's just run git log for "master..RELx_y_STABLE"
    for each branch, rather than all the way back.
    This doesn't seem more reliable to me in any way. Looking at the
    actual commit history must surely be more reliable than assuming you
    know what it is. I think what you should be doing is using git log
    --decorate and extracting the information from that as you go by.
    I looked at doing that but it didn't seem like an improvement. Take
    a look at the new version and see what you think.

    regards, tom lane
  • Robert Haas at Sep 27, 2010 at 1:03 am

    On Sun, Sep 26, 2010 at 8:24 PM, Tom Lane wrote:
    Robert Haas <robertmhaas@gmail.com> writes:
    On Sun, Sep 26, 2010 at 4:38 PM, Tom Lane wrote:
    Hah, I have a plan.  Let's just run git log for "master..RELx_y_STABLE"
    for each branch, rather than all the way back.
    This doesn't seem more reliable to me in any way.  Looking at the
    actual commit history must surely be more reliable than assuming you
    know what it is.  I think what you should be doing is using git log
    --decorate and extracting the information from that as you go by.
    I looked at doing that but it didn't seem like an improvement.  Take
    a look at the new version and see what you think.
    I'm not really sure. I suppose I'll have to play with it for a while
    to really form a clear opinion. Clearly, knowing which minor releases
    a commit is in is a major improvement, but the whole thing is so
    heavily re-engineered from my original version that I'm not really
    sure whether there's anything else that I care about that got broken
    in the process. In particular, I'm wondering to what extent we're
    baking in branch management conventions from which we may wish to
    depart at some point in the future.

    I maintain that if someone else whacked around one of your commits the
    way you whacked this around, you'd bite their head off.

    --
    Robert Haas
    EnterpriseDB: http://www.enterprisedb.com
    The Enterprise Postgres Company
  • Tom Lane at Sep 27, 2010 at 1:09 am

    Robert Haas writes:
    On Sun, Sep 26, 2010 at 8:24 PM, Tom Lane wrote:
    I looked at doing that but it didn't seem like an improvement.  Take
    a look at the new version and see what you think.
    I'm not really sure. I suppose I'll have to play with it for a while
    to really form a clear opinion. Clearly, knowing which minor releases
    a commit is in is a major improvement, but the whole thing is so
    heavily re-engineered from my original version that I'm not really
    sure whether there's anything else that I care about that got broken
    in the process. In particular, I'm wondering to what extent we're
    baking in branch management conventions from which we may wish to
    depart at some point in the future.
    If we ever start doing things like sub-branches it's likely to need
    more work, but I suggest that that would have been true anyway.
    I don't believe that the current version shows a different set of
    commits from the original (other than endpoint bugs...).
    I maintain that if someone else whacked around one of your commits the
    way you whacked this around, you'd bite their head off.
    I apologize if I offended you. I hadn't believed that there was any
    particular consensus on how this script ought to behave; I thought
    it was something you'd whipped up in an hour based on my request for
    something like cvs2cl, and that making it work more like that would be
    uncontroversial.

    regards, tom lane
  • Bruce Momjian at Oct 14, 2010 at 9:43 am

    Tom Lane wrote:
    I maintain that if someone else whacked around one of your commits the
    way you whacked this around, you'd bite their head off.
    I apologize if I offended you. I hadn't believed that there was any
    particular consensus on how this script ought to behave; I thought
    it was something you'd whipped up in an hour based on my request for
    something like cvs2cl, and that making it work more like that would be
    uncontroversial.
    I am hoping git_changelog wil be like pgcvslog so I can easily create
    the 9.1 major release notes someday.

    --
    Bruce Momjian <bruce@momjian.us> http://momjian.us
    EnterpriseDB http://enterprisedb.com

    + It's impossible for everything to be true. +
  • Gurjeet Singh at Sep 27, 2010 at 1:14 am

    On Mon, Sep 27, 2010 at 3:03 AM, Robert Haas wrote:
    On Sun, Sep 26, 2010 at 8:24 PM, Tom Lane wrote:
    I maintain that if someone else whacked around one of your commits the
    way you whacked this around, you'd bite their head off.
    :) Yes, he would. And you are not being any less forgiving either.

    #ilovepostgrescommunity

    --
    gurjeet.singh
    @ EnterpriseDB - The Enterprise Postgres Company
    http://www.EnterpriseDB.com

    singh.gurjeet@{ gmail | yahoo }.com
    Twitter/Skype: singh_gurjeet

    Mail sent from my BlackLaptop device
  • Robert Haas at Sep 27, 2010 at 1:21 am

    On Sun, Sep 26, 2010 at 9:14 PM, Gurjeet Singh wrote:
    On Mon, Sep 27, 2010 at 3:03 AM, Robert Haas wrote:
    On Sun, Sep 26, 2010 at 8:24 PM, Tom Lane wrote:
    I maintain that if someone else whacked around one of your commits the
    way you whacked this around, you'd bite their head off.
    :) Yes, he would. And you are not being any less forgiving either.

    #ilovepostgrescommunity
    I actually do love the PostgreSQL community, and I really enjoy
    working with Tom. This does not mean that we won't disagree about
    things some times, and I do put on my flame-retardant undergarments
    every time I sit down to read -hackers. That's OK. It's still an
    awesome community, and that is why I put the time and effort into it
    that I do (he writes at 9PM on a Sunday night).

    --
    Robert Haas
    EnterpriseDB: http://www.enterprisedb.com
    The Enterprise Postgres Company
  • Gurjeet Singh at Sep 27, 2010 at 1:52 am

    On Mon, Sep 27, 2010 at 3:20 AM, Robert Haas wrote:
    On Sun, Sep 26, 2010 at 9:14 PM, Gurjeet Singh wrote:
    On Mon, Sep 27, 2010 at 3:03 AM, Robert Haas wrote:
    On Sun, Sep 26, 2010 at 8:24 PM, Tom Lane wrote:
    I maintain that if someone else whacked around one of your commits the
    way you whacked this around, you'd bite their head off.
    :) Yes, he would. And you are not being any less forgiving either.

    #ilovepostgrescommunity
    I actually do love the PostgreSQL community, and I really enjoy
    working with Tom. This does not mean that we won't disagree about
    things some times, and I do put on my flame-retardant undergarments
    every time I sit down to read -hackers. That's OK. It's still an
    awesome community, and that is why I put the time and effort into it
    that I do (he writes at 9PM on a Sunday night).
    Just to clarify my intentions, I wasn't trying to enjoy the disagreement,
    nor trying to lablel it as or feed the flaming. Just trying to make a point
    that here everyone is treated equal.

    Regards,
    --
    gurjeet.singh
    @ EnterpriseDB - The Enterprise Postgres Company
    http://www.EnterpriseDB.com

    singh.gurjeet@{ gmail | yahoo }.com
    Twitter/Skype: singh_gurjeet

    Mail sent from my BlackLaptop device
  • David Christensen at Sep 27, 2010 at 2:34 am

    On Sep 26, 2010, at 2:24 PM, Tom Lane wrote:

    I wrote:
    I think we could get that behavior fairly easily by remembering the last
    tag matching one of the commits on a branch, as we chase the branch
    backwards.
    I find that this works just fine for the branches, but not so well for
    master, because more often than not the initial RELx_y_z tag is applied
    on the release's branch and not on master. So for example commits on
    master appear to jump from REL7_2 development to REL8_0 development,
    because 7.3 and 7.4 have no release tag on the master branch.

    We could perhaps fix that if there were an inexpensive way to get the
    SHA1 of the master commit that each branch is sprouted from. However,
    I'm inclined to propose that we instead manually place a tag at each
    sprout point. Any thoughts about that? In particular, what should
    the naming convention for such tags be? I would have liked to use
    RELx_y, but that's out because before 8.0 we named the initial
    releases that way.

    Particularly with PostgreSQL's linear branch history, `git merge-base` will show you the point at which the branches diverged from master:

    $ git merge-base origin/REL9_0_STABLE master
    1084f317702e1a039696ab8a37caf900e55ec8f2

    $ git show 1084f317702e1a039696ab8a37caf900e55ec8f2
    commit 1084f317702e1a039696ab8a37caf900e55ec8f2
    Author: Marc G. Fournier <scrappy@hub.org>
    Date: Fri Jul 9 02:43:12 2010 +0000

    tag beta3

    Also, the `git describe` command can be used to identify the closest tag a specific commit is a part of:

    $ git describe --tags 6d297e0551a2a3cc048655796230cdff5e559952
    REL9_0_BETA2-153-g6d297e0

    This indicates that the indicated commit is the 153rd commit after the REL9_0_BETA2 tag (and includes the abbreviated SHA1 for unique identification in the case that there are multiple branches which have since been re-merged; not the case in this project, but still handy for uniqueness).

    The command `git branch --contains` will come in handy for commits which are the exact same content (ignoring the commit parentage and time and using only the patch-id (`git --help patch-id`)). This obviously won't catch commits where the changed content had to be modified in the back-patching process, but could serve as a quick basis. (In truth, this may be relatively useless, as I tried to find an example which included back-branches, but wasn't able to find an example off-hand.) In any case, the option exists... :-)

    $ git branch -a --contains 2314baef38248b31951d3c8e285e6f8e4fd7dd05
    * master
    remotes/origin/HEAD -> origin/master
    remotes/origin/REL8_4_STABLE
    remotes/origin/REL8_5_ALPHA1_BRANCH
    remotes/origin/REL8_5_ALPHA2_BRANCH
    remotes/origin/REL8_5_ALPHA3_BRANCH
    remotes/origin/REL9_0_ALPHA4_BRANCH
    remotes/origin/REL9_0_ALPHA5_BRANCH
    remotes/origin/REL9_0_STABLE
    remotes/origin/master

    Regards,

    David
    --
    David Christensen
    End Point Corporation
    david@endpoint.com
  • Tom Lane at Sep 27, 2010 at 2:45 am

    David Christensen writes:
    On Sep 26, 2010, at 2:24 PM, Tom Lane wrote:
    We could perhaps fix that if there were an inexpensive way to get the
    SHA1 of the master commit that each branch is sprouted from.
    Particularly with PostgreSQL's linear branch history, `git merge-base` will show you the point at which the branches diverged from master:
    $ git merge-base origin/REL9_0_STABLE master
    1084f317702e1a039696ab8a37caf900e55ec8f2
    Ah-hah, I figured there had to be some plumbing command that would get that.
    The current version of the script siphons the information off from git
    log --parents, but it'd likely be cleaner to do it with git merge-base.
    It might be a bit slower though --- some experimentation here says that
    git merge-base takes a bit of time, which isn't surprising if I'm right
    in guessing that it has to chase back from the two branch heads looking
    for a commit in common. That's going to basically duplicate work that
    git log has to do also.

    regards, tom lane

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedSep 26, '10 at 3:48p
activeOct 14, '10 at 9:43a
posts24
users6
websitepostgresql.org...
irc#postgresql

People

Translate

site design / logo © 2022 Grokbase