Re: can git-describe learn first-parent behavior?

From: Michael J Gruber <git@drmicha.warpmail.net>
Date: Sep 21, 2010, 09:34 UTC
Message-ID: <4C987C2E.3060001@drmicha.warpmail.net>
In-Reply-To: <AANLkTi=6o15y-6Q+tn40=hrPf9pmo+Y1Jd97hGxr5mH2@mail.gmail.com>

Joshua Shrader venit, vidit, dixit 21.09.2010 07:58:

Show 10 quoted lines

> This seems like it would be a rather useful feature.  Suppose a
> maintenance branch, maint/v1.0, is forked from master, and the branch
> point is tagged something like "v1.0-stable".  The next commit on
> master is tagged "v2.0-base", indicating that it is the first commit
> of the new release.  Suppose two releases are made - a release for
> public consumption of version 1.0, and a release for internal testing
> from master (currently 2.0), and we want to embed the output of
> git-describe into the builds.  If bugs were fixed on 1.0, and then 1.0
> was merged into master, it seems perfectly possible to run
> git-describe on master, but get the v1.0 tag in the output.

The earlier tag (in terms of depth) wins, yes.

> Is this just a poor workflow?  Am I using git-describe incorrectly?
> Or, does a first-parent option to git-describe seem useful?
> 
> Thanks for the input.

If you know you want to describe HEAD based on v2 tags you can use

git describe --match v2\* --tags HEAD

"git describe" does not use the revision walk machinery so that it does not have the --first-parent option. I'm not sure how useful that is, but it's easy to implement.

Michael