在 git log 中显示所有标签

show all tags in git log

提问by Jonathan

Why does git log --decoratenot display more than one tag per commit?

为什么git log --decorate每次提交不显示多个标签？

EDIT: Charles Bailey has come up with the answer (at least in my case)
Essentially, I had one tag that pointed to another tag that pointed to the commit. Because of this extra layer of indirection, the tag wasn't showing up in the log. I'll have to fix this, wither by fixing our tagging script to tag correctly, or by some shell script voodoo to recursively follow tags. Anyway, I'll leave this question up just for reference in case anyone wants it. (I'm new to stack overflow, but I assume that is the correct protocol?)

编辑：Charles Bailey 提出了答案（至少在我的情况下）
本质上，我有一个标签指向另一个指向提交的标签。由于这个额外的间接层，标签没有出现在日志中。我必须解决这个问题，通过修复我们的标记脚本来正确标记，或者通过一些 shell 脚本 voodoo 来递归跟踪标记。无论如何，我会留下这个问题仅供参考，以防有人需要。（我是堆栈溢出的新手，但我认为这是正确的协议？）

... Original question follows ...

...原始问题如下...

Backstory: We use GIT at work for source control, and we have a policy of always tagging a commit when we deploy. (It's actually a script that does tags, and then pulls the tag on the server). Since it's a web application with separate staging and production servers, we often tag a release for staging (for testing or whatever), and then later tag the same commit for production.

背景故事：我们在工作中使用 GIT 进行源代码控制，并且我们有一个策略，即在部署时始终标记提交。（它实际上是一个做标签的脚本，然后在服务器上拉取标签）。由于它是一个具有单独的暂存和生产服务器的 Web 应用程序，我们经常标记一个发布用于暂存（用于测试或其他），然后标记相同的提交用于生产。

So it's actually very often that we have multiple tags on the same commit. It would be very nice to be able to see this in the text log, but it doesn't seem to support it. I'm currently working around the issue by manually checking the tag I'm looking for, or by firing up gitk. While both of these solutions work, it seems to me that it's really weird for git log --decorateto only support one tag per commit by default.

所以实际上很多时候我们在同一个提交上有多个标签。能够在文本日志中看到这一点会非常好，但它似乎不支持它。我目前正在通过手动检查我要查找的标签或启动gitk. 虽然这两种解决方案都有效，但在我看来git log --decorate，默认情况下每次提交只支持一个标签真的很奇怪。

I did some googling around, but didn't find much. Am I missing something obvious?

我在谷歌上搜索了一些，但没有找到太多。我错过了一些明显的东西吗？

P.S. (I actually use a custom format string with %d, according to the man pages and some quick tests, it's equivalent to --decorate)

PS（我实际上使用自定义格式字符串%d，根据手册页和一些快速测试，它相当于--decorate）

采纳答案by VonC

Note about tag of tag (tagging a tag), which is at the origin of your issue, as Charles Baileycorrectly pointed out in the comment:

请注意标记的标记（标记标记），这是您问题的根源，正如Charles Bailey在评论中正确指出的那样：

Make sure you study this thread, as overriding a signed tag is not as easy:

确保你研究了这个线程，因为覆盖签名标签并不容易：

• if you already pushed a tag, the git tagman pageseriously advised against a simple git tag -f Bto replace a tag name "A"

• don't try to recreate a signed tag with git tag -f(see the thread extract below)

  (it is about a corner case, but quite instructive about tags in general, and it comes from another SO contributor Jakub Nar?bski):

• 如果你已经推送了一个标签，git tag手册页严重建议不要简单git tag -f B地替换标签名称“ A”

• 不要尝试重新创建签名标签git tag -f（请参阅下面的线程摘录）

  （这是一个角落案例，但总的来说对标签很有启发性，它来自另一位 SO 贡献者Jakub Nar?bski）：

Please note that the name of tag (heavyweight tag, i.e. tag object) is stored in two places:

• in the tag object itself as a contents of 'tag' header (you can see it in output of "git show <tag>" and also in output of "git cat-file -p <tag>", where <tag>is heavyweight tag, e.g. v1.6.3in git.gitrepository),
• and also is default name of tag reference (reference in "refs/tags/*" namespace) pointing to a tag object.
  Note that the tag reference(appropriate reference in the "refs/tags/*" namespace) is purely localmatter; what one repository has in 'refs/tags/v0.1.3', other can have in 'refs/tags/sub/v0.1.3' for example.

So when you create signed tag 'A', you have the following situation (assuming that it points at some commit)

请注意标签的名称（重量级标签，即标签对象）存储在两个地方：

• 在标签对象本身作为“标签”标头的内容（您可以在“ git show <tag>”的输出和“ ”的输出中看到它git cat-file -p <tag>，其中<tag>重量级标签，例如v1.6.3在git.git存储库中），
• 也是refs/tags/*指向标签对象的标签引用的默认名称（在“ ”命名空间中的引用）。
  请注意，标记引用（“ refs/tags/*” 命名空间中的适当引用）纯粹是本地问题；例如，一个存储库在“ refs/tags/v0.1.3”中有什么，其他存储库在“ ”中有什么refs/tags/sub/v0.1.3。

因此，当您创建签名标签 ' A' 时，您会遇到以下情况（假设它指向某个提交）

  35805ce   <--- 5b7b4ead  <=== refs/tags/A
  (commit)       tag A
                 (tag)

Please also note that "git tag -f A A" (notice the absence of options forcing it to be an annotated tag) is a noop - it doesn't change the situation.

If you do "git tag -f -s A A": note that you forceowerwriting a tag (so git assumes that you know what you are doing), and that one of -s/ -a/ -moptions is used to force annotated tag (creation of tag object), you will get the following situation

还请注意，“ git tag -f A A”（注意没有选项强制它成为带注释的标签）是一个 noop - 它不会改变情况。

如果你这样做“ git tag -f -s A A“：注意你的力owerwriting标签（这样的git假设你知道你在做什么），和一个-s/ -a/-m选项用于强制标注的标签（创建标签的对象），您将得到以下情况

  35805ce   <--- 5b7b4ea  <--- ada8ddc  <=== refs/tags/A
  (commit)       tag A         tag A
                 (tag)         (tag)

Note also that "git show A" would show the whole chain down to the non-tag object...

另请注意，“ git show A” 会将整个链向下显示到非标记对象...

回答by Marcello de Sales

git log --no-walk --tags --pretty="%h %d %s" --decorate=full

This version will print the commit message as well:

这个版本也会打印提交信息：

 $ git log --no-walk --tags --pretty="%h %d %s" --decorate=full
3713f3f  (tag: refs/tags/1.0.0, tag: refs/tags/0.6.0, refs/remotes/origin/master, refs/heads/master) SP-144/ISP-177: Updating the package.json with 0.6.0 version and the README.md.
00a3762  (tag: refs/tags/0.5.0) ISP-144/ISP-205: Update logger to save files with optional port number if defined/passed: Version 0.5.0
d8db998  (tag: refs/tags/0.4.2) ISP-141/ISP-184/ISP-187: Fixing the bug when loading the app with Gulp and Grunt for 0.4.2
3652484  (tag: refs/tags/0.4.1) ISP-141/ISP-184: Missing the package.json and README.md updates with the 0.4.1 version
c55eee7  (tag: refs/tags/0.4.0) ISP-141/ISP-184/ISP-187: Updating the README.md file with the latest 1.3.0 version.
6963d0b  (tag: refs/tags/0.3.0) ISP-141/ISP-184: Add support for custom serializers: README update
4afdbbe  (tag: refs/tags/0.2.0) ISP-141/ISP-143/ISP-144: Fixing a bug with the creation of the logs
e1513f1  (tag: refs/tags/0.1.0) ISP-141/ISP-143: Betterr refactoring of the Loggers, no dependencies, self-configuration for missing settings.

回答by VonC

Note: the commit 5e1361cfrom brian m. carlson (bk2204)(for git 1.9/2.0 Q1 2014) deals with a special case in term of log decoration with tags:

注意：来自brian m的提交 5e1361c 。carlson ( bk2204)(for git 1.9/2.0 Q1 2014) 处理带有标签的日志装饰方面的特殊情况：

log: properly handle decorations with chained tags

日志：正确处理带有链式标签的装饰

git logdid not correctly handle decorations when a tag object referenced another tag object that was no longer a ref, such as when the second tag was deleted.
The commit would not be decorated correctly because parse_objecthad not been called on the second tag and therefore its tagged field had not been filled in, resulting in none of the tags being associated with the relevant commit.

Call parse_objectto fill in this field if it is absent so that the chain of tags can be dereferenced and the commit can be properly decorated.
Include tests as well to prevent future regressions.

git log当一个标签对象引用另一个不再是 ref 的标签对象时，没有正确处理装饰，例如当第二个标签被删除时。
提交不会被正确修饰，因为parse_object没有在第二个标签上调用，因此它的标记字段没有被填充，导致没有任何标签与相关提交相关联。

parse_object如果此字段不存在，则调用以填充此字段，以便可以取消引用标签链并正确修饰提交。
还包括测试以防止未来的回归。

Example:

例子：

git tag -a tag1 -m tag1 &&
git tag -a tag2 -m tag2 tag1 &&
git tag -d tag1 &&
git commit --amend -m shorter &&
git log --no-walk --tags --pretty="%H %d" --decorate=full