On Sat, 17 Oct 2009, Junio C Hamano wrote:
Julian Phillips <julian@xxxxxxxxxxxxxxxxx> writes:
My interest in this thread is solely that it might provide a mechanism
to find out which tag was checked out.
Hmm, what is lacking in "git describe HEAD" for that? I am not
complaining that you might be asking for something that exists, but I _do_
want to know if something that exists is not a satisfactory solution and
if so how it can be improved.
What is lacking is the "checked out" part. "git describe HEAD" will
tell me _a_ tag that matches the currently checked out state.
However, it makes no guarantee that it was the one I checked out. If
I tag the code with "v1.0.0", and a colleague later tags it with
"this_version_sucks", then when I check out and build the code for the
customer the version it reports could well be "this_version_sucks"
instead of "v1.0.0" ...
I think I understand why you think showing what you gave to your last "git
checkout" (e.g. "checkout origin/master" or "checkout v1.0.0") and using
that as a build identification token is a good idea. But "origin/master"
is a moving target---it depends on when you checked it out. describe uses
tags and does not use branch heads for a good reason.
For my purposes the branch that I built from is much more useful than the
output from describe. Releases are always made from tags, but for builds
used in the lab it is generally much more useful to know which branch was
built directly rather than being able to find the exact commit that was
built.
"v1.0.0" also is to a lessor degree, as you may have tagged v1.0.0 locally
and somebody else also has used the tag for a different version, but a tag
is far less likely to move due to social convention. "describe --long"
would make sure this won't be an issue anyway, though.
For any particular release only one person is given the job of making the
release tag, so we don't have the problem of multiple instances of the
same tag - but we do need to make sure that the version output is the
correct tag.
--
Julian
---
Water, taken in moderation cannot hurt anybody.
-- Mark Twain
--
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