mostrar todas las etiquetas en git log

¿Por qué git log --decorateno muestra más de una etiqueta por confirmación?

EDITAR : Charles Bailey ha encontrado la respuesta (al menos en mi caso)
Esencialmente, tenía una etiqueta que apuntaba a otra etiqueta que apuntaba a la confirmación. Debido a esta capa adicional de indirección, la etiqueta no aparecía en el registro. Tendré que arreglar esto, ya sea arreglando nuestro script de etiquetado para etiquetar correctamente, o mediante algún script de shell vudú para seguir etiquetas de forma recursiva. De todos modos, dejaré esta pregunta solo como referencia en caso de que alguien la quiera. (Soy nuevo en el desbordamiento de pila, pero supongo que ese es el protocolo correcto)

... Sigue la pregunta original ...

Trasfondo: utilizamos GIT en el trabajo para el control de código fuente y tenemos la política de etiquetar siempre una confirmación cuando implementamos. (En realidad, es un script que hace etiquetas y luego extrae la etiqueta en el servidor). Dado que es una aplicación web con servidores de ensayo y de producción separados, a menudo etiquetamos una versión para su ensayo (para pruebas o lo que sea) y luego etiquetamos el mismo compromiso para producción.

Entonces, en realidad, es muy frecuente que tengamos varias etiquetas en la misma confirmación. Sería muy bueno poder ver esto en el registro de texto, pero no parece ser compatible. Actualmente estoy solucionando el problema comprobando manualmente la etiqueta que estoy buscando o activando gitk. Si bien ambas soluciones funcionan, me parece que es realmente extraño git log --decorateadmitir solo una etiqueta por confirmación de forma predeterminada.

Busqué en Google, pero no encontré mucho. ¿Me estoy perdiendo algo obvio?

PD (de hecho, uso una cadena de formato personalizado con %d, de acuerdo con las páginas de manual y algunas pruebas rápidas, es equivalente a --decorate)

Nota sobre la etiqueta de la etiqueta (etiquetar una etiqueta), que está en el origen de su problema, como Charles Bailey señaló correctamente en el comentario:

Asegúrese de estudiar este hilo , ya que anular una etiqueta firmada no es tan fácil:

• si ya ha enviado una etiqueta, la git tagpágina de manual desaconsejó seriamente la git tag -f Bsustitución de un nombre de etiqueta " A"

• no intente volver a crear una etiqueta firmada con git tag -f(consulte el extracto del hilo a continuación)

  (se trata de un caso de esquina, pero bastante instructivo sobre las etiquetas en general, y proviene de otro colaborador de SO, Jakub Narębski ):

Tenga en cuenta que el nombre de la etiqueta (etiqueta de peso pesado, es decir, objeto de etiqueta) se almacena en dos lugares:

• en el objeto de etiqueta en sí como contenido del encabezado 'etiqueta' (puede verlo en la salida de " git show <tag>" y también en la salida de " git cat-file -p <tag>", donde <tag>está la etiqueta de peso pesado, por ejemplo, v1.6.3en el git.gitrepositorio),
• y también es el nombre predeterminado de la referencia de etiqueta (referencia en " refs/tags/*" espacio de nombres) que apunta a un objeto de etiqueta.
  Tenga en cuenta que la referencia de la etiqueta ( referencia apropiada en el " refs/tags/*" espacio de nombres) es un asunto puramente local ; lo que un repositorio tiene en " refs/tags/v0.1.3", otro puede tener en " refs/tags/sub/v0.1.3, por ejemplo.

Entonces, cuando crea una etiqueta firmada ' A', tiene la siguiente situación (asumiendo que apunta a algún compromiso)

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

Tenga en cuenta también que " git tag -f A A" (observe la ausencia de opciones que obliguen a que sea una etiqueta anotada) no es una opción, no cambia la situación.

Si lo hace " git tag -f -s A A": tenga en cuenta que fuerza la escritura de una etiqueta (por lo que git asume que sabe lo que está haciendo), y que una de las opciones -s/ -a/ -mse usa para forzar la etiqueta anotada (creación de un objeto de etiqueta), obtendrá el siguiente situación

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

Tenga en cuenta también que " git show A" mostraría toda la cadena hasta el objeto sin etiqueta ...

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

Esta versión también imprimirá el mensaje de confirmación:

 $ 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: la confirmación 5e1361c de brian m. carlson ( bk2204) (para git 1.9 / 2.0 Q1 2014) trata un caso especial en términos de decoración de troncos con etiquetas:

registro: maneje adecuadamente las decoraciones con etiquetas encadenadas

git logno manejaba correctamente las decoraciones cuando un objeto de etiqueta hacía referencia a otro objeto de etiqueta que ya no era una referencia, como cuando se eliminó la segunda etiqueta .
La confirmación no se decoraría correctamente porque parse_objectno se había llamado en la segunda etiqueta y, por lo tanto, su campo etiquetado no se había completado, lo que hacía que ninguna de las etiquetas se asociara con la confirmación relevante.

Llame parse_objectpara completar este campo si está ausente para que la cadena de etiquetas pueda desreferenciarse y la confirmación pueda decorarse correctamente.
Incluya también pruebas para evitar futuras regresiones.

Ejemplo:

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