Joshua Shrader venit, vidit, dixit 21.09.2010 07:58: > 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html