]> git.ipfire.org Git - thirdparty/git.git/commit - t/t6120-describe.sh
describe: force long format for a name based on a mislocated tag
authorJunio C Hamano <gitster@pobox.com>
Thu, 20 Feb 2020 17:34:36 +0000 (09:34 -0800)
committerJunio C Hamano <gitster@pobox.com>
Fri, 21 Feb 2020 02:05:33 +0000 (18:05 -0800)
commitff165f00c1065d94c0bcab8708364e6dc5655f5d
tree7262fdc26d7f0416bffeafe8cfa97786b3179037
parentb6d4d82bd5a49197d5d2f4f81c08da0d461cfcf1
describe: force long format for a name based on a mislocated tag

An annotated tag has two names: where it sits in the refs/tags
hierarchy and the tagname recorded in the "tag" field in the object
itself.  They usually should match.

Since 212945d4 ("Teach git-describe to verify annotated tag names
before output", 2008-02-28), a commit described using an annotated
tag bases its name on the tagname from the object.  While this was a
deliberate design decision to make it easier to converse about tags
with others, even if the tags happen to be fetched to a different
name than it was given by its creator, it had one downside.

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, describing a commit whose parent is v1.0-bob
would result in "v1.0" (i.e. the tagname taken from the tag object)
followed by "-1-gXXXXX" where XXXXX is the abbreviated object name,
and a string that ends with "-g" followed by a hexadecimal string is
an object name for the object whose name begins with hexadecimal
string (as long as it is unique), so it does not matter if the
leading part is "v1.0" or "v1.0-bob".

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.

While at it, remove an overly cautious dead code to protect against
an annotated tag object without the tagname.  Such a tag is filtered
out much earlier in the codeflow, and will not reach this part of
the code.

Helped-by: Matheus Tavares <matheus.bernardino@usp.br>
Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
builtin/describe.c
t/t6120-describe.sh