tag - ¿Cómo ordenar las etiquetas git por orden de cadena de versión del formulario rc-XYZW?

¿qué hace git log-oneline?

Question

Cuando ingreso un comando:

git tag -l

Obtengo tales resultados:

rc-0.9.0.0
rc-0.9.0.1
rc-0.9.0.10
rc-0.9.0.11
rc-0.9.0.12
rc-0.9.0.2
rc-0.9.0.3
rc-0.9.0.4
rc-0.9.0.5
rc-0.9.0.6
rc-0.9.0.7
rc-0.9.0.8
rc-0.9.0.9

En lugar de esto, quiero:

rc-0.9.0.0
rc-0.9.0.1
rc-0.9.0.2
rc-0.9.0.3
rc-0.9.0.4
rc-0.9.0.5
rc-0.9.0.6
rc-0.9.0.7
rc-0.9.0.8
rc-0.9.0.9
rc-0.9.0.10
rc-0.9.0.11
rc-0.9.0.12

¿Cómo es posible ordenar la lista actual para obtener esos resultados?

Answer 1

Adapte este script perl , que ordena las etiquetas que se parecen a client_release/7.2/7.2.25 , a su esquema de etiquetado específico.

Answer 2

Con Git 2.0 (junio de 2014), ¡podrá especificar un orden de clasificación!

Ver commit b6de0c6 , del commit 9ef176b , escrito por Nguyễn Thái Ngọc Duy ( pclouds ) :

 --sort=<type>

Ordenar en un orden específico .
El tipo admitido es:

• " refname " (orden lexicográfica),
• " version:refname " o " v:refname " (los nombres de las etiquetas se tratan como versiones).

Prefijo " - " para invertir el orden de clasificación.

Entonces, si tienes:

git tag foo1.3 &&
git tag foo1.6 &&
git tag foo1.10

Esto es lo que obtendrías:

# lexical sort
git tag -l --sort=refname "foo*"
foo1.10
foo1.3
foo1.6

# version sort
git tag -l --sort=version:refname "foo*"
foo1.3
foo1.6
foo1.10

# reverse version sort
git tag -l --sort=-version:refname "foo*"
foo1.10
foo1.6
foo1.3

# reverse lexical sort
git tag -l --sort=-refname "foo*"
foo1.6
foo1.3
foo1.10

Desde commit b150794 (por Jacob Keller, git 2.1.0, agosto de 2014), puede especificar el orden predeterminado:

tag.sort

Esta variable controla el ordenamiento de las etiquetas cuando se muestra con git-tag .
Sin la --sort=<value> " --sort=<value> " proporcionada, el valor de esta variable se usará como el predeterminado.

robinst comments :

el orden de clasificación de la versión ahora se puede configurar (Git 2.1+) como predeterminado:

git config --global tag.sort version:refname

Con Git 2.4 (Q2 2015) , la variable de configuración versionsort.prerelease se puede usar para especificar que v1.0-pre1 viene antes de v1.0 .

Ver commit f57610a por Junio ​​C Hamano ( gitster ) .

^{Nota (ver a continuación) versionsort.prereleaseSuffix es ahora (2017) un alias obsoleto para versionsort.suffix .}

git 2.7.1 (febrero de 2016) mejorará la salida de la git tag sí.

Ver commit 0571979 (26 de enero de 2016), y cometer 1d094db (24 de enero de 2016) por Jeff King ( peff ) .
^{(Fusionada por Junio ​​C Hamano - gitster - in commit 8bad3de , 01 feb 2016)}

tag : no mostrar nombres de etiqueta ambiguos como " tags/foo "

Desde b7cc53e ( tag.c : use API '' ref-filter '', 2015-07-11), la git tag ha comenzado a mostrar etiquetas con nombres ambiguos (es decir, cuando existen tanto " heads/foo " como " tags/foo ") como " tags/foo " en lugar de solo " foo ".
Esto es a la vez:

• inútil; la salida de " git tag " incluye solo refs/tags , por lo que sabemos que " foo " significa la que está en " refs/tags ".
• y ambiguo; en la salida original, sabemos que la línea " foo " significa que existe " refs/tags/foo ". En el nuevo resultado, no está claro si nos referimos a " refs/tags/foo " o " refs/tags/tags/foo ".

La razón por la que esto sucede es que commit b7cc53e cambió la git tag para usar el formato de salida " %(refname:short) " del ref-filter, que fue adaptado de for-each-ref . Este código más general no sabe que solo nos importan las etiquetas, y usa shorten_unambiguous_ref para obtener el short-name .
Necesitamos decirle que solo nos preocupamos por " refs/tags/ ", y debe acortarse con respecto a ese valor.

agreguemos un nuevo modificador al lenguaje de formato, " strip ", para eliminar un conjunto específico de componentes de prefijo.
Esto corrige " git tag " y permite a los usuarios invocar el mismo comportamiento desde sus propios formatos personalizados (para " tag " o " for-each-ref ") dejando " :short " con el mismo significado consistente en todos los lugares.

Si se agrega strip=<N> , quita <N> componentes de ruta separados por barras del frente del refname (p. Ej., %(refname:strip=2) convierte refs/tags/foo en foo .
<N> debe ser un entero positivo.
Si una referencia mostrada tiene menos componentes que <N> , el comando aborta con un error.

Para la git tag , cuando no se especifica, el valor predeterminado es %(refname:strip=2) .

Actualizar Git 2.12 (Q1 2017)

Consulte commit c026557 , commit b178464 , commit 51acfa9 , commit b823166 , commit 109064a , commit 0c1b487 , commit 9ffda48 , commit eba286e (08 Dec 2016) por SZEDER Gábor ( szeder ) .
^{(Fusionado por Junio ​​C Hamano - gitster - in commit 1ac244d , 23 ene 2017)}

versionsort.prereleaseSuffix es un alias obsoleto para versionsort.suffix .

La función prereleaseSuffix de la comparación de versiones que se usa en " git tag -l " no funcionaba correctamente cuando estaban presentes dos o más versiones previas para la misma versión (por ejemplo, cuando 2.0 , 2.0-beta1 y 2.0-beta2 están allí y el código necesita comparar 2.0-beta1 y 2.0-beta2 ).

Answer 3

De acuerdo con esta answer , en las plataformas que no admiten sort -V como Windows y OSX, puede usar

git tag -l | sort -n -t. -k1,1 -k2,2 -k3,3 -k4,4

Answer 4

Para obtener una clasificación inversa con el método de sort -V :

git tag -l | sort -V --reverse

Answer 5

Terminé escribiendo un simple script de shell para simplificar esta tarea.

#!/usr/bin/env bash

TAGS=$(git tag)
CODE=$?

if [ $CODE = 0 ]; then
    echo "$TAGS" | sort -V
fi

exit $CODE

Guardé eso como git-tags en mi $PATH y ejecuto git tags cada vez que necesito listar etiquetas.

Answer 6

Usar tipo de versión

git tag -l | sort -V

o para la versión de git> = 2.0

git tag -l --sort=v:refname
git tag -l --sort=-v:refname # reverse