84

In the following lines:

$ git tag -n1
v1.8        Tagged the day before yesterday
v1.9        Tagged yesterday
v2.0        Tagged today
$ git describe
v1.9-500-ga6a8c67
$

Can anyone explain why the v2.0 tag is not used by "git describe", and how to fix this? The v2.0 tag is already pushed, so I am guessing that I can't just delete and re-add it.

nhahtdh
  • 55,989
  • 15
  • 126
  • 162
knipknap
  • 5,934
  • 7
  • 39
  • 43

4 Answers4

113

git describe uses only annotated tags by default. Specify the --tags option to make it use lightweight tags as well.

Make sure you've checked out the correct commit (git rev-parse HEAD). Annotated tags are created with git tag -a. If you do git show <tagname> and you see the commit only, it's a lightweight tag; if you see an additional tag message, it's an annotated tag.

Pang
  • 9,564
  • 146
  • 81
  • 122
knittl
  • 246,190
  • 53
  • 318
  • 364
  • 13
    "git describe --tags" produces the same output as above. – knipknap Nov 11 '10 at 12:54
  • you can also try `--all` to make it use all refs. is HEAD described by the tag? (just to make sure) – knittl Nov 11 '10 at 12:55
  • "git describe --all" prints "heads/master". The v2.0 tag is applied on the master branch. (I suppose that means it describes HEAD?) – knipknap Nov 11 '10 at 13:06
  • `HEAD` is the currently checked out commit. – knittl Nov 11 '10 at 13:07
  • Ah, yes, HEAD is currently checked out. How to I tell whether a tag is annotated? "git tag" does not seem to have an option to show this. – knipknap Nov 11 '10 at 13:09
  • 1
    make sure you've checked out the correct commit (`git rev-parse HEAD`) – also make sure you use the latest version of git. annotated tags are created with `git tag -a`. if you do `git show ` and you see the commit, it's a lightweight tag, if you see a tag message it's an annotated tag. – knittl Nov 11 '10 at 13:11
  • Ah-ha. "git show v1.9" prints the tag and the commit, while "git show v2.0" prints the commit only. Using `git tag -fa -m "Release 2.0" v2.0 785b92df5` fixed it. Thanks! (If you edit the original posting I can mark your answer.) – knipknap Nov 11 '10 at 13:32
31

When this happened to us, it was a case of two tags applied for the same commit. You can find if this is the case by running

# git log --oneline --decorate=short
deba4b4 (tag: v1.1.0.20.0, tag: v1.1.0.19.0) 001 New buildnumber

Here there are two tags, one for version 19 and other for 20. 20 was tagged after 19, but for the same commit. In this case describe returned

# git describe --tags
v1.1.0.19.0

I don't know why it did this, but this is how it seems to work with duplicate tags.

Another case where this might happen is if you have a tag that is more "near" to you in a branch. That case has been explained in this blog post.

eis
  • 51,991
  • 13
  • 150
  • 199
  • 1
    I am having a similar issue, so I figured the best way would be to prevent creating duplicate annotated tags. Do you know how I could achieve that? – Jorge Bucaran Nov 22 '15 at 05:49
  • @jbucaran I guess you'd need to run a check and then tag or not tag based on that. that'd probably be topic for another question – eis Nov 22 '16 at 15:34
26

The issue is git tag shows all tags in all branches while git describe only uses tags on commits which are available in the current branch.

Here is an example (the reason why I came here actually):

 $ git tag | tail -n3
v0.4.0
v0.4.1
v0.4.2

It shows the latest tag available is v0.4.2, but this is my output of git describe:

 $ git describe --tags
v0.4.0-2-acd334c

I'm on develop branch. When I dig into the log, I see indeed the most recent tags are not available on the current branch:

 $ git log --oneline --decorate=short | grep 'tag\:' | head -n3
acd334c (tag: v0.4.0) Merge pull request #1061
988fe5e (tag: v0.3.6) Merge pull request #859
5f97274 (tag: v0.3.5) Merge pull request #646

So in my case, the developers decided to create a new release branch exclusively for tagging releases which results that the develop branch is not up to date with the tags anymore.

Hope that helps and thanks @eis for the idea with checking the logs.

q9f
  • 11,293
  • 8
  • 57
  • 96
3

Most likely from your example, v1.9 is a tag from merge commit.

It is expected git behavior by default and you can read more about it here: https://git.kernel.org/pub/scm/git/git.git/commit/?id=80dbae03

To ignore merge tags when looking for most recent on the current branch you can use --first-parent option. 

git describe --tags --first-parent --abbrev=0

--first-parent

Follow only the first parent commit upon seeing a merge commit. This is useful when you wish to not match tags on branches merged in the history of the target commit.

Ref: https://git-scm.com/docs/git-describe

Haris
  • 4,130
  • 3
  • 30
  • 47