Re: Bug in 'git describe' if I have two tags on the same commit.

From: Istvan Pato <istvan.pato@gmail.com>
Date: Feb 14, 2017, 08:07 UTC
Message-ID: <CAOcUJQzEKoCf3T2AVzck1Y4NWb8N9FMqQ=+6z6-9C4YF8-jQzA@mail.gmail.com>
In-Reply-To: <xmqqo9y5de1k.fsf@gitster.mtv.corp.google.com>

This is my fault: this is a lightweight tag. Thank you!

2017-02-13 21:35 GMT+01:00 Junio C Hamano <gitster@pobox.com>:

Show 34 quoted lines

> Kevin Daudt <me@ikke.info> writes:
>
>> On Sun, Feb 12, 2017 at 01:15:22PM +0100, Istvan Pato wrote:
>>
>>> (master) [1] % git show-ref --tag
>>> 76c634390... refs/tags/1.0.0
>>> b77c7cd17... refs/tags/1.1.0
>>> b77c7cd17... refs/tags/1.2.0
>>>
>>> (master) % git describe --tags --always
>>> 1.1.0-1-ge9e9ced
>>>
>>> ### Expected: 1.2.0
>>> ...
>>
>> Are these lightweight tags? Only annotated tags have a date associated
>> to them, which is where the rel-notes refers to.
>
> Good eyes.  The fact that the two points at the same object means
> that even if they were both annotated tags, they have the same
> tagger dates.
>
> If the code that compares the candidates and picks better tag to
> describe the object with knows the refnames of these "tags", I'd
> imagine that we could use the versioncmp() logic as the final tie
> breaker, but I do not offhand remember if the original refname we
> took the tag (or commit) from is propagated that deep down the
> callchain.  It probably does not, so some code refactoring may be
> needed if somebody wants to go in that direction.
>
>
>
>
>