Re: [COMMITTERS] pgsql: Still more tweaking of git_changelog.

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
divergedfrom 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
SHA1for unique identification in the case that there are multiple branches which have since been re-merged; not the
casein 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
commitparentage and time and using only the patch-id (`git --help patch-id`)).  This obviously won't catch commits
wherethe changed content had to be modified in the back-patching process, but could serve as a quick basis.  (In truth,
thismay be relatively useless, as I tried to find an example which included back-branches, but wasn't able to find an
exampleoff-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_BRANCHremotes/origin/REL8_5_ALPHA3_BRANCH remotes/origin/REL9_0_ALPHA4_BRANCH
remotes/origin/REL9_0_ALPHA5_BRANCHremotes/origin/REL9_0_STABLE remotes/origin/master 

Regards,

David
--
David Christensen
End Point Corporation
david@endpoint.com