show all tags in git log_问答_开发者_运维开发者技术经验分享

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

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?)

... Original question follows ...

Backsto开发者_StackOverflowry: 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.

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 --decorate to only support one tag per commit by default.

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)

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.

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

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

if you already pushed a tag, the git tag man page seriously advised against a simple git tag -f B to 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):

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.3 in git.git repository),

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 local matter; 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)

  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 force owerwriting a tag (so git assumes that you know what you are doing), and that one of -s / -a / -m options is used to force annotated tag (creation of tag object), you will get the following situation

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

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

log: properly handle decorations with chained tags

git log did 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_object had 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_object to 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.

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

Note: I am just addressing the subject of the question (emphasis added):

show all tags in git log

...not the specific details of the question.

Show the full `git log` (in color!) for each tagged commit:

I really think this is the most-useful and most-beautiful form to show all tags:

# standard, multi-line `git log` output
git log --no-walk --tags

# concise, one-line `git log` output
git log --no-walk --tags --oneline

It shows the full git log output for every single commit which has a tag attached to it. Very handy!

Trying to make sense of the option descriptions in man git log, I think that --tags causes git log to show all tags even if the tag is not on a commit otherwise in the git log ancestry tree, and --no-walk tell it to show only the tags rather than walking the tree and showing all non-tagged commits too. The --oneline option, of course, is added to get a concise output of one line per commit (tag actually, in this case).

And if you'd like to filter out just tags which match a certain string search pattern, do this instead:

# multi-line output
git log --no-walk --tags=*some_string*

# one-line output
git log --no-walk --tags=*some_string* --oneline

Example:

git log --no-walk --tags=*release/my_board*

Alternative 1-line `git log` summary (in color!) for each tagged commit:

If you'd like to see a little more info. in your one-line-per-tagged-commit output, do this instead. Note: this is modified from Coderwall's beautiful git lg alias:

# fancy one-line output
git log --color --no-walk --tags --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit

# vs regular one-line output
git log --no-walk --tags --oneline

Here is some sample output from the official "Stable" version of the Linux kernel:

"fancy" one-line command and output

linux_stable$ git log --color --no-walk --tags --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit
650093916eb3 - (tag: v6.0.12, origin/linux-6.0.y) Linux 6.0.12 (5 days ago) <Greg Kroah-Hartman>
d9790301361c - (tag: v5.15.82, origin/linux-5.15.y) Linux 5.15.82 (5 days ago) <Greg Kroah-Hartman>
592346d5dc9b - (tag: v5.10.158, origin/linux-5.10.y) Linux 5.10.158 (5 days ago) <Greg Kroah-Hartman>
316cdfc48d4d - (tag: v5.4.226, origin/linux-5.4.y) Linux 5.4.226 (5 days ago) <Greg Kroah-Hartman>
e8fff2341723 - (tag: v4.19.268, origin/linux-4.19.y) Linux 4.19.268 (5 days ago) <Greg Kroah-Hartman>
65afe34ac33d - (tag: v4.14.301, origin/linux-4.14.y) Linux 4.14.301 (5 days ago) <Greg Kroah-Hartman>
b6097015eea4 - (tag: v4.9.335, origin/linux-4.9.y) Linux 4.9.335 (5 days ago) <Greg Kroah-Hartman>
76dcd734eca2 - (tag: v6.1-rc8) Linux 6.1-rc8 (8 days ago) <Linus Torvalds>
31e4bdd2c25b - (tag: v6.0.11) Linux 6.0.11 (10 days ago) <Greg Kroah-Hartman>
e4a7232c917c - (tag: v5.15.81) Linux 5.15.81 (10 days ago) <Greg Kroah-Hartman>

regular one-line command and output at the exact same point in time

linux_stable$ git log --no-walk --tags --oneline
650093916eb3 (tag: v6.0.12, origin/linux-6.0.y) Linux 6.0.12
d9790301361c (tag: v5.15.82, origin/linux-5.15.y) Linux 5.15.82
592346d5dc9b (tag: v5.10.158, origin/linux-5.10.y) Linux 5.10.158
316cdfc48d4d (tag: v5.4.226, origin/linux-5.4.y) Linux 5.4.226
e8fff2341723 (tag: v4.19.268, origin/linux-4.19.y) Linux 4.19.268
65afe34ac33d (tag: v4.14.301, origin/linux-4.14.y) Linux 4.14.301
b6097015eea4 (tag: v4.9.335, origin/linux-4.9.y) Linux 4.9.335
76dcd734eca2 (tag: v6.1-rc8) Linux 6.1-rc8
31e4bdd2c25b (tag: v6.0.11) Linux 6.0.11
e4a7232c917c (tag: v5.15.81) Linux 5.15.81

And of course you can still filter on just certain tags you want using the --tags=*some_string* form instead:

git log --color --no-walk --tags=*some_string* --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit

Example:

git log --color --no-walk --tags=*release/my_board* --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit