mostrar todas as tags no git log

Por que git log --decoratenão exibe mais de uma tag por confirmação?

EDIT : Charles Bailey veio com a resposta (pelo menos no meu caso)
Essencialmente, eu tinha uma tag que apontava para outra tag que apontava para o commit. Por causa dessa camada extra de indireção, a tag não estava aparecendo no log. Terei que consertar isso, definhar corrigindo nosso script de marcação para marcar corretamente ou por algum vodu de script de shell para seguir as marcações recursivamente. De qualquer forma, vou deixar essa questão de lado apenas para referência, caso alguém queira. (Sou novo no estouro de pilha, mas presumo que seja o protocolo correto?)

... Segue-se a pergunta original ...

História de fundo: Usamos GIT no trabalho para controle de origem e temos uma política de sempre marcar um commit quando implantamos. (Na verdade, é um script que faz tags e, em seguida, puxa a tag no servidor). Como é um aplicativo da web com servidores de teste e produção separados, geralmente marcamos uma versão para teste (para teste ou qualquer outra coisa) e, posteriormente, marcamos o mesmo commit para produção.

Portanto, é muito comum termos várias tags no mesmo commit. Seria muito bom poder ver isso no log de texto, mas parece que não dá suporte. No momento, estou resolvendo o problema verificando manualmente a tag que estou procurando ou ativando gitk. Embora ambas as soluções funcionem, me parece realmente estranho git log --decoratesuportar apenas uma tag por commit por padrão.

Fiz algumas pesquisas no Google, mas não achei muito. Estou perdendo algo óbvio?

PS (Na verdade, uso uma string de formato personalizado com %d, de acordo com as páginas do manual e alguns testes rápidos, é equivalente a --decorate)

Observação sobre tag de tag (marcar uma tag), que está na origem de seu problema, como Charles Bailey corretamente apontou no comentário:

Certifique-se de estudar este tópico , pois substituir uma tag assinada não é tão fácil:

• se você já enviou uma tag, a git tagpágina de manual aconselhou seriamente contra uma simples git tag -f Bsubstituição de um nome de tag " A"

• não tente recriar uma tag assinada com git tag -f(veja o extrato do tópico abaixo)

  (trata-se de um caso esquivo, mas bastante instrutivo sobre tags em geral, e vem de outro colaborador do SO, Jakub Narębski ):

Observe que o nome da tag (tag pesada, ou seja, objeto tag) é armazenado em dois lugares:

• no próprio objeto tag como um conteúdo do cabeçalho 'tag' (você pode vê-lo na saída de " git show <tag>" e também na saída de " git cat-file -p <tag>", onde <tag>é a tag pesada, por exemplo, v1.6.3no git.gitrepositório),
• e também é o nome padrão da referência de tag (referência no refs/tags/*namespace " ") apontando para um objeto de tag.
  Observe que a referência da tag ( referência apropriada no refs/tags/*namespace " ") é uma questão puramente local ; o que um repositório tem em ' refs/tags/v0.1.3', outro pode ter em ' refs/tags/sub/v0.1.3' por exemplo.

Então, quando você cria uma tag assinada ' A', você tem a seguinte situação (assumindo que ela aponta para algum commit)

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

Observe também que " git tag -f A A" (observe a ausência de opções forçando-o a ser uma tag anotada) é um noop - não muda a situação.

Se você fizer " git tag -f -s A A": observe que você força owerwriting uma tag (então o git assume que você sabe o que está fazendo), e que uma das opções -s/ -a/ -mé usada para forçar a tag anotada (criação do objeto tag), você obterá o situação seguinte

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

Observe também que " git show A" mostraria toda a cadeia até o objeto não tag ...

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

Esta versão imprimirá a mensagem de confirmação também:

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

Nota: o commit 5e1361c de brian m. carlson ( bk2204) (para git 1.9 / 2.0 Q1 2014) trata de um caso especial em termos de decoração de log com tags:

registro: manuseie adequadamente as decorações com etiquetas encadeadas

git lognão manipulava corretamente as decorações quando um objeto de tag fazia referência a outro objeto de tag que não era mais uma referência, como quando a segunda tag era excluída .
O commit não seria decorado corretamente porque parse_objectnão foi chamado na segunda tag e, portanto, seu campo marcado não foi preenchido, resultando em nenhuma das tags sendo associada ao commit relevante.

Chame parse_objectpara preencher este campo se estiver ausente para que a cadeia de tags possa ser desreferenciada e o commit possa ser devidamente decorado.
Inclua também testes para evitar futuras regressões.

Exemplo:

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