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 diverged from master:

$ git merge-base origin/REL9_0_STABLE master
1084f317702e1a039696ab8a37caf900e55ec8f2

$ git show 1084f317702e1a039696ab8a37caf900e55ec8f2
commit 1084f317702e1a039696ab8a37caf900e55ec8f2
Author: Marc G. Fournier <scrappy(at)hub(dot)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(at)endpoint(dot)com