Cómo mostrar la confirmación de git utilizando el número de confirmaciones desde una label

Con git describe puedes get el número de confirmaciones desde la última label. Si solo tenía la label y el número de confirmaciones, ¿cuál es la mejor manera de mostrar la confirmación que se describió?

Sé que podrías usar git log tag.. y canalizarlo a un script que hace el conteo, pero esperaba una solución más elegante similar a git show tag~n .

Para agregar más context, estamos planeando usar git describe para crear numbers de lanzamiento, por ejemplo con

 $ git describe v1.5-39-g5ede964 

usaríamos foo_1.5.39. Lo que nos gustaría hacer es saber que 1.5.39 significa el compromiso número 39 después de la label v1.5, encontrar esa confirmación, es decir, encontrar g5ede964. Como se señala en un comentario, la 39ª confirmación después de la v1.5 puede no ser única. Entonces, quizás una mejor manera de preguntar esto es cuál es la mejor forma de encontrar todos los commits X de forma tal que si HEAD estuviera apuntando a X git describe que devolverá v1.5-39-***** .

Lo que estás pidiendo es imposible en el caso general. El número de confirmaciones por sí solo no puede decirle nada si hay alguna fusión en su historial.

Por ejemplo, dada la siguiente estructura de repo:

 a - b - c - d - h \ / e - f - g 

Con una label puesta en a , las salidas de git describe d y git describe g son idénticas salvo para SHA1:

 > git describe d tag-3-ge8dca33 > git describe g tag-3-g4fecc2e 

Dicho esto, si no tienes un montón de twigs paralelas funcionando a la vez, entonces podrás resolver un determinado número de confirmación a una única confirmación, pero si tienes una sola twig lateral activa en el momento de su label, entonces esto puede no funcionar.

Si necesita numbers de lanzamiento confiables, debe apegarse a las tags explícitas.

Tratar

 git rev-list tag..HEAD --count 

O

 git rev-list tag.. --count 

Quieren decir lo mismo.

Si está buscando el número de confirmaciones desde la última label, lo siguiente funcionó para mí

 git rev-list `git rev-list --tags --no-walk --max-count=1`..HEAD --count 

Usted puede:

 git log --oneline tag.. | wc -l 

esto le dará la cantidad de confirmaciones

Como explicó la respuesta de Kevin , esto generalmente no es posible. Para resolver el problema en casos especiales, mencionó:

Dicho esto, si no tienes un montón de twigs paralelas funcionando a la vez, entonces podrás resolver un determinado número de confirmación a una única confirmación, pero si tienes una sola twig lateral activa en el momento de su label, entonces esto puede no funcionar.

puede usar el siguiente command (siendo n el número de confirmaciones desde la label)

 git rev-list tag..HEAD --reverse | awk NR==n 

¿ v1.5-39-***** es la mejor forma de encontrar todos los commits X de modo que si HEAD apuntaba a X git describe devolvería v1.5-39-*****

sigue siendo la pregunta equivocada La pregunta correcta es

cómo encontrar todos los commits X de modo que si HEAD estaba apuntando a X un ordinario git describe podría haber devuelto v1.5-39-*****

y no es tan fácil responder eso. Aún así, en ausencia de acción enemiga este procedimiento enumerará el compromiso correcto tal vez entre otras posibilidades:

 ancestor=v1.5 n=39 git rev-list --all --reverse --topo-order --parents --ancestry-path ^$ancestor \ | awk ' function minmore( i) { for ( i=2; i <= NF; ++i ) if ( gen[$i] > gen[$1] ) gen[$1]=gen[$i] return ++gen[$1] } minmore()<=n { print "[[ $(git rev-list --count "ancestor".."$1") == "n" ]] &&" print " git describe --match="ancestor" "$1 } ' ancestor=$ancestor n=$n \ # | sh # lose the first `#` here to actually run the generated checks 

El motivo de la incertidumbre y la complejidad es que git describe solo intenta get una base razonable, por lo que (consulte sus documentos ) elegirá las tags actuales más cercanas que pueda ver, y contará cuántas confirmaciones adicionales hay en la historia descrita, y generar un apodo de esa manera. Por ejemplo, las nuevas tags pueden cambiar su base preferida de tal manera que una git describe ya no generaría ese apodo; y aunque los SHA son inmutables, las references se pueden reescribir.