"git describe" ignores a tag

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.

Solution 1:

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.

Solution 2:

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.

Solution 3:

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.

Solution 4:

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