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 <scra...@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
da...@endpoint.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
