show all tags in git log

Question

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

User · Answer

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  amp  amp  git tag -a tag2 -m tag2 tag1  amp  amp  git tag -d tag1  amp  amp  git commit --amend -m shorter  amp  amp  git log --no-walk --tags --pretty   H  d  --decorate full

User · Answer

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

User · Answer

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 Narebski        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  lt tag gt   and also in output of  git cat-file -p  lt tag gt    where  lt tag gt  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    lt --- 5b7b4ead   lt     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    lt --- 5b7b4ea   lt --- ada8ddc   lt     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 all tags in git log

... Original question follows ...

The answer is

Examples related to git

Tags