threads / bug / 45118

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

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

## tl;dr

4 messages between Feb 12, 2017 and Feb 14, 2017.

replies: 3people: 3as markdown or json

Istvan Pato· Feb 12, 2017, 12:15 UTC · lore

I didn't get back the latest tag by 'git describe --tags --always' if I have two tags on the same commit.

// repository ppa:git-core/ppa

(master)⚡ % cat /etc/lsb-release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=16.04 DISTRIB_CODENAME=xenial DISTRIB_DESCRIPTION="Ubuntu 16.04.2 LTS"

(master)⚡ % git --version git version 2.11.0

(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
References:
https://www.kernel.org/pub/software/scm/git/docs/RelNotes-1.7.1.1.txt
* "git describe" did not tie-break tags that point at the same commit
  correctly; newer ones are preferred by paying attention to the
  tagger date now.
http://stackoverflow.com/questions/8089002/git-describe-with-two-tags-on-the-same-commit

Thanks, Istvan Pato

Kevin Daudt· Feb 13, 2017, 15:44 UTC · re: Istvan Pato · lore

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

On Sun, Feb 12, 2017 at 01:15:22PM +0100, Istvan Pato wrote:
Show 36 quoted lines
> I didn't get back the latest tag by 'git describe --tags --always' if
> I have two tags on the same commit.
> 
> // repository ppa:git-core/ppa
> 
> (master)⚡ % cat /etc/lsb-release
> DISTRIB_ID=Ubuntu
> DISTRIB_RELEASE=16.04
> DISTRIB_CODENAME=xenial
> DISTRIB_DESCRIPTION="Ubuntu 16.04.2 LTS"
> 
> (master)⚡ % git --version
> git version 2.11.0
> 
> (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
> 
> References:
> 
> https://www.kernel.org/pub/software/scm/git/docs/RelNotes-1.7.1.1.txt
> 
> * "git describe" did not tie-break tags that point at the same commit
>   correctly; newer ones are preferred by paying attention to the
>   tagger date now.
> 
> http://stackoverflow.com/questions/8089002/git-describe-with-two-tags-on-the-same-commit
> 
> Thanks,
> Istvan Pato

Are these lightweight tags? Only annotated tags have a date associated to them, which is where the rel-notes refers to.

Junio C Hamano· Feb 13, 2017, 20:35 UTC · re: Kevin Daudt · lore

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

Kevin Daudt <me@ikke.info> writes:
Show 15 quoted lines
> 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.

Istvan Pato· Feb 14, 2017, 08:07 UTC · re: Junio C Hamano · lore

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

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.
>
>
>
>
>

← back to recent threads