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

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.

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