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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Kevin Daudt <me@xxxxxxxxx> 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.








[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]