Re: [PATCH] Proof-of-concept patch to remember what the detached HEAD was
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Oct 17, 2009, 17:43 UTC
- Message-ID
- <7vljj97w7u.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <alpine.LNX.2.00.0910171617580.6644@reaper.quantumfyre.co.uk>
Julian Phillips <julian@quantumfyre.co.uk> writes:
Show 15 quoted lines
>>> 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.
"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.