“git describe”忽略标签
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/4154485/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
"git describe" ignores a tag
提问by knipknap
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.
谁能解释为什么“git describe”不使用 v2.0 标签，以及如何解决这个问题？v2.0 标签已经推送了，所以我猜我不能只是删除并重新添加它。
回答by knittl
git describeuses only annotated tags by default. specify the --tagsoption to make it use lightweight tags as well
git describe默认情况下仅使用带注释的标签。指定--tags选项以使其也使用轻量级标签
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 additionial tag message it's an annotated tag.
确保您已检出正确的提交 ( git rev-parse HEAD)。带注释的标签是用git tag -a. 如果您这样做git show <tagname>并且您只看到提交，则它是一个轻量级标签，如果您看到附加标签消息，则它是一个带注释的标签。
回答by eis
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
这里有两个标签，一个用于版本 19，另一个用于 20。20 被标记在 19 之后，但用于相同的提交。在这种情况下描述返回
# 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.
另一种可能发生这种情况的情况是，如果您在分支中有一个离您更“近”的标签。该案例已在此博客文章中进行了解释。
回答by Afr
The issue is git tagshows alltags in all branches while git describeonly uses tags on commits which are available in the current branch.
问题是在所有分支中git tag显示所有标签，而git describe只在当前分支中可用的提交上使用标签。
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:
它显示可用的最新标签是v0.4.2，但这是我的输出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 releasebranch 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.
希望能帮助并感谢@eis 检查日志的想法。
回答by Haris D.
Most likely from your example, v1.9is a tag from merge commit.
最有可能来自您的示例，v1.9是来自合并提交的标签。
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
默认情况下，git 行为是预期的，您可以在此处阅读有关它的更多信息：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-parentoption.
要在当前分支上查找最新时忽略合并标签，您可以使用--first-parent选项。
git describe --tags --first-parent --abbrev=0
--first-parent
--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.
看到合并提交后，只关注第一个父提交。当您希望不匹配目标提交历史记录中合并的分支上的标签时，这很有用。
