Come ordinare i tag git per ordine di stringa della versione del modulo rc-XYZW?

Quando inserisco un comando:

git tag -l 

Ottengo risultati simili:

 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 

Invece di questo voglio:

 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 

Come è ansible ordinare l’elenco corrente per ottenere tali risultati?

    Usa ordinamento versione

     git tag -l | sort -V 

    o per versione git> = 2.0

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

    Con Git 2.0 (giugno 2014), sarai in grado di specificare un ordine di smistamento!

    Vedi commit b6de0c6 , da commit 9ef176b , creato da Nguyễn Thái Ngọc Duy ( pclouds ) :

      --sort= 

    Ordina in un ordine specifico .
    Il tipo supportato è:

    • refname ” (ordine lessicografico),
    • version:refname ” o ” v:refname ” (i nomi dei tag sono trattati come versioni).

    Prepend ” - ” per invertire l’ordine.


    Quindi, se hai:

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

    Ecco cosa otterresti:

     # 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 

    Dal commit b150794 (di Jacob Keller, git 2.1.0, agosto 2014), puoi specificare quell’ordine predefinito:

     tag.sort 

    Questa variabile controlla l’ordinamento dei tag quando visualizzati da git-tag .
    Senza l’opzione ” --sort= “, il valore di questa variabile verrà utilizzato come predefinito.

    commenti robinst :

    ora l’ordinamento della versione può essere configurato (Git 2.1+) come predefinito:

     git config --global tag.sort version:refname 

    Con Git 2.4 (Q2 2015) , la variabile di configurazione versionsort.prerelease può essere utilizzata per specificare che v1.0-pre1 viene prima della v1.0 .

    Vedi commit f57610a di Junio ​​C Hamano ( gitster ) .

    Nota (vedi sotto) versionsort.prereleaseSuffix è ora (2017) un alias deprecato per versionsort.suffix .


    git 2.7.1 (febbraio 2016) migliorerà l’output del git tag stesso.

    Vedi commit 0571979 (26 gennaio 2016) e commit 1d094db (24 gennaio 2016) di Jeff King ( peff ) .
    (Unita da Junio ​​C Hamano – gitster – in commit 8bad3de , 01 feb 2016)

    tag : non mostrare nomi di tag ambigui come ” tags/foo

    Poiché b7cc53e ( tag.c : utilizza le API ‘ ref-filter ‘, 2015-07-11), il git tag ha iniziato a mostrare tag con nomi ambigui (cioè, quando sia ” heads/foo ” che ” tags/foo ” esiste) come ” tags/foo ” invece di solo ” foo “.
    Questo è entrambi:

    • inutile; l’output di ” git tag ” include solo refs/tags , quindi sappiamo che ” foo ” significa quello in ” refs/tags “.
    • e ambiguo; nell’output originale, sappiamo che la riga ” foo ” significa che ” refs/tags/foo ” esiste. Nel nuovo output non è chiaro se intendiamo ” refs/tags/foo ” o ” refs/tags/tags/foo “.

    La ragione per cui ciò accade è che commit b7cc53e ha cambiato git tag per usare la formattazione dell’output del filtro ref ” %(refname:short) “, che è stata adattata da for-each-ref . Questo codice più generale non sa che ci interessano solo i tag e utilizza shorten_unambiguous_ref per ottenere il short-name .
    Dobbiamo dire che ci preoccupiamo solo di ” refs/tags/ ” e che dovrebbe essere abbreviato rispetto a quel valore.

    aggiungiamo un nuovo modificatore alla lingua di formattazione, ” strip “, per rimuovere uno specifico set di componenti di prefisso.
    Questo risolve ” git tag ” e consente agli utenti di invocare lo stesso comportamento dai loro formati personalizzati (per ” tag ” o ” for-each-ref “) lasciando ” :short ” con lo stesso significato coerente in tutti i punti.

    Se strip= viene aggiunto, strisce componenti del percorso separati dalla barra dalla parte anteriore del refname (es. %(refname:strip=2) trasforma refs/tags/foo in foo .
    deve essere un numero intero positivo.
    Se un riferimento visualizzato ha meno componenti di , il comando interrompe con un errore.

    Per il git tag , quando non specificato, il valore predefinito è %(refname:strip=2) .


    Aggiornamento Git 2.12 (primo trimestre 2017)

    Vedere commit c026557 , commit b178464 , commit 51acfa9 , commit b823166 , commit 109064a , commit 0c1b487 , commit 9ffda48 , commit eba286e (08 dic 2016) di SZEDER Gábor ( szeder ) .
    (Unito da Junio ​​C Hamano – gitster – in commit 1ac244d , 23 gen 2017)

    versionsort.prereleaseSuffix è un alias deprecato per versionsort.suffix .

    La funzionalità prereleaseSuffix del confronto delle versioni utilizzato in ” git tag -l ” non è stata eseguita correttamente quando erano presenti due o più prerelease per lo stesso rilascio (ad esempio quando 2.0 , 2.0-beta1 e 2.0-beta2 sono presenti e il codice deve confrontare 2.0-beta1 e 2.0-beta2 ).

    Secondo questa risposta , su piattaforms che non supportano sort -V come Windows e OSX, è ansible utilizzare

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

    Adatta questo script perl , che ordina tag che assomigliano a client_release/7.2/7.2.25 , al tuo specifico schema di tagging.

    Ho finito per scrivere un semplice script di shell per semplificare questo compito.

     #!/usr/bin/env bash TAGS=$(git tag) CODE=$? if [ $CODE = 0 ]; then echo "$TAGS" | sort -V fi exit $CODE 

    L’ho salvato come git-tags nel mio $PATH ed eseguito git tags ogni volta che ho bisogno di elencare i tag.

    Per ottenere un ordinamento inverso con l’approccio di sort -V :

     git tag -l | sort -V --reverse