Re: [PATCH] describe: output tag's ref instead of embedded name

> Junio C Hamano <gitster@pobox.com> writes:
> 
> > Coming back to the original topic, ...
> >
> >> If a tag describes a commit, we currently output not the tag's ref but
> >> its embedded name. This means that when the tag is locally stored under
> >> a different name, the output given cannot be used to access the tag in
> >> any way. A warning is also emitted in this case, but the message is not
> >> very enlightening:
> >
> > None of the above is wrong per-se, but the reason why we chose to
> > use the real name of the tag in the tag object, while issuing a
> > warning, was so that people can correct the mistake of storing an
> > annotated tag A to a wrong refname Q.  If "describe" gave a name
> > based on refname Q, there is no incentive to correct the situation
> > to use the right refname.  The name that describes the commits
> > relative to the real name of the A is *not* usable by design, until
> > the refname is corrected (i.e. the tag is stored in the right
> > place).
> >
> > So I am not 100% confident that the original patch is a good idea.
> 
> FWIW, this design came from 212945d4 ("Teach git-describe to verify
> annotated tag names before output", 2008-02-28).  Shawn was quite
> explicit that use of the real name was deliberate:
> 
>     If an annotated tag describes a commit we want to favor the name
>     listed in the body of the tag, rather than whatever name it has
>     been stored under locally.  By doing so it is 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.
> 
> and I tend to agree with the original rationale.