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. "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. -- 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