On Thu, Feb 20, 2020 at 2:34 PM Junio C Hamano <gitster@xxxxxxxxx> wrote: > [...] > Another thing that is not satisfying is what should happen in "all" > mode. We add "tags/" prefix so in the case we've been discussing, > the output would be "tags/v1.0-0-g0123456", but the whole reason why > we add the prefix is to say that the early part of the name, "v1.0", > is a tag, and it would be natural to associate it with refs/tags/v1.0 > that is *not* Bob's tag. Yeah, that is not very satisfying, but at least the emitted warning would make the user think twice before wrongly associating refs/tags/v1.0 with Bob's tag? > Having said all that, here is what I have at this moment. > > -- >8 -- > Subject: describe: force long format for a name based on a mislocated tag [...] > > The output from "git describe", at least in the modern Git, should > be usable as an object name to name the exact commit given to the > "git describe" command. Using the tagname, when two names differ, > breaks this property, when describing a commit that is directly > pointed at by such a tag. An annotated tag Bob made as "v1.0" may > sit at "refs/tags/v1.0-bob" in the ref hierarchy, and output from > "git describe v1.0-bob^0" would say "v1.0", but there may not be > any tag at "refs/tags/v1.0" locally or there may be another tag that > points at a different object. > > Note that this won't be a problem if a commit being described is not > directly pointed at by such a mislocated tag. In the example in the > previous paragraph, "git describe v1.0-bob~1" would result in "v1.0" > (i.e. the tagname taken from the tag object) followed by "-1-gXXXXX" I now this is just an illustration, but shouldn't this example be "git describe --contains v1.0-bob~1"? Otherwise, I think the tag wouldn't be found as it comes after the given commit. Testing here without --contains I get the error "fatal: No tags can describe <sha1 hash>" However, when using --contains, the output is also not what I expected. It doesn't fail, but I get "v1.0-bob~1". I.e., it not only prints the refname instead of the tagname but also don't print any warnings... This is not what we want, right? > Show the name in the long format, i.e. with "-0-gXXXXX" suffix, when > the name we give is based on a mislocated annotated tag to ensure > that the output can be used as the object name for the object > originally given to the command to fix the issue. Another case that came to my mind is when the user runs `git describe --abrev=0 HEAD` and v1.0-bob points to HEAD~. In this case, v1.0 will be displayed without suffix, so it is not usable at get_oid(). Should we, perhaps, also force the long output in this case? And talking about the forced long output, using `--abbrev=0` in HEAD (i.e. tag: v1.0-bob), after the patch, will make the complete hash be displayed. This might be an unnecessary cosmetic nitpick, but we might want to follow the default behavior when --long is given and use just as many digits as necessary?
