2010-11-11 9 views
37

En las siguientes líneas:"git describir" hace caso omiso de una etiqueta

$ git tag -n1 
v1.8  Tagged the day before yesterday 
v1.9  Tagged yesterday 
v2.0  Tagged today 
$ git describe 
v1.9-500-ga6a8c67 
$ 

¿Alguien puede explicar por qué la etiqueta v2.0 no es utilizado por "git describir", y cómo solucionar este problema? La etiqueta v2.0 ya está presionada, así que supongo que no puedo simplemente eliminarla y volver a agregarla.

+0

Ver también https://stackoverflow.com/questions/33851344/git-describe-fails-to-return-most-recent-annotated-tag – caw

Respuesta

48

git describe usa solo etiquetas con anotaciones predeterminadas. especifique la opción --tags para que también use etiquetas livianas

asegúrese de haber comprobado la confirmación correcta (git rev-parse HEAD). Las etiquetas anotadas se crean con git tag -a. si haces git show <tagname> y ves el compromiso solamente, es una etiqueta ligera, si ves un mensaje de etiqueta adicional es una etiqueta anotada.

+5

"git describe --tags" produce el mismo resultado que el anterior. – knipknap

+0

también puedes probar '--all' para usar todas las referencias. es HEAD descrito por la etiqueta? (solo para asegurarse) – knittl

+0

"git describe --all" imprime "heads/master". La etiqueta v2.0 se aplica en la rama principal. (Supongo que eso significa que describe HEAD?) – knipknap

13

Cuando esto nos sucedió, se trataba de dos etiquetas aplicadas para la misma confirmación. Usted puede encontrar que si este es el caso, mediante la ejecución de

# git log --oneline --decorate=short 
deba4b4 (tag: v1.1.0.20.0, tag: v1.1.0.19.0) 001 New buildnumber 

Aquí hay dos etiquetas, una para la versión 19 y otra de 20. 20 fue etiquetado después del 19, pero por el mismo comprometerse. En este caso describen regresado

# git describe --tags 
v1.1.0.19.0 

No sé por qué se hizo esto, pero esta es la forma en que parece que funciona con etiquetas duplicadas.

Otro caso donde esto podría suceder es si tiene una etiqueta que está más "cerca" de usted en una sucursal. Ese caso ha sido explicado en this blog post.

+0

Tengo un problema similar, así que pensé que la mejor manera sería evitar la creación de etiquetas anotadas duplicadas. ¿Sabes cómo podría lograr eso? –

+0

@jbucaran Supongo que necesitaría ejecutar un cheque y luego etiquetar o no etiquetar según eso. eso probablemente sería tema para otra pregunta – eis

6

La cuestión es git tag espectáculos todas las etiquetas en todas las ramas, mientras que git describe sólo utiliza etiquetas de confirmaciones que están disponibles en la corriente rama.

Aquí es un ejemplo (la razón por la que vine aquí en realidad):

$ git tag | tail -n3 
v0.4.0 
v0.4.1 
v0.4.2 

Se muestra la última etiqueta disponible es v0.4.2, pero esta es mi salida del git describe:

$ git describe --tags 
v0.4.0-2-acd334c 

I Estoy en desarrollo rama. Cuando cavo en el registro, veo de hecho las etiquetas más recientes no están disponibles en la rama actual:

$ git log --oneline --decorate=short | grep '\(tag\:' | head -n3 
acd334c (tag: v0.4.0) Merge pull request #1061 
988fe5e (tag: v0.3.6) Merge pull request #859 
5f97274 (tag: v0.3.5) Merge pull request #646 

Así que en mi caso, los desarrolladores decidieron crear una nueva rama liberación exclusivamente para el etiquetado de comunicados de los cuales resultados que la rama de desarrollo ya no está actualizada con las etiquetas.

Espero que ayude y gracias @eis por la idea de verificar los registros.

Cuestiones relacionadas