Re: [PATCH] Proof-of-concept patch to remember what the detached HEAD was
- From
Julian Phillips <julian@quantumfyre.co.uk>
- Date
- Oct 17, 2009, 22:19 UTC
- Message-ID
- <alpine.LNX.2.00.0910172257270.9794@reaper.quantumfyre.co.uk>
- In-Reply-To
- <7vljj97w7u.fsf@alter.siamese.dyndns.org>
On Sat, 17 Oct 2009, Junio C Hamano wrote:
Show 23 quoted lines
> Julian Phillips <julian@quantumfyre.co.uk> 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