80 votes

"git describe" ignore une balise

Dans les lignes qui suivent :

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

Quelqu'un peut-il expliquer pourquoi la balise v2.0 n'est pas utilisée par "git describe", et comment y remédier ? La balise v2.0 est déjà poussée, donc je suppose que je ne peux pas simplement l'effacer et la réinsérer.

113voto

knittl Points 64110

git describe n'utilise par défaut que les balises annotées. Spécifiez l'option --tags pour qu'il utilise également des balises légères.

Assurez-vous d'avoir vérifié le bon commit ( git rev-parse HEAD ). Les balises annotées sont créées avec git tag -a . Si vous le faites git show <tagname> et que vous ne voyez que le commit, il s'agit d'une balise légère ; si vous voyez un message de balise supplémentaire, il s'agit d'une balise annotée.

29voto

eis Points 14687

Lorsque cela nous est arrivé, il s'agissait de deux étiquettes appliquées pour le même engagement. Vous pouvez vérifier si c'est le cas en lançant

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

Ici, il y a deux étiquettes, l'une pour la version 19 et l'autre pour la version 20. La version 20 a été étiquetée après la 19, mais pour le même commit. Dans ce cas, describe renvoie

# git describe --tags
v1.1.0.19.0

Je ne sais pas pourquoi il a fait cela, mais c'est ainsi qu'il semble fonctionner avec les balises dupliquées.

Un autre cas où cela peut se produire est celui où vous avez une étiquette qui est plus "proche" de vous dans une branche. Ce cas a été expliqué dans cet article de blog .

26voto

vertoe Points 688

Il s'agit de git tag spectacles tous dans toutes les branches, tandis que git describe n'utilise que les tags sur les commits qui sont disponibles dans la base de données actuelle de branche .

Voici un exemple (la raison pour laquelle je suis venu ici en fait) :

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

Il indique que la dernière balise disponible est v0.4.2 mais c'est ce que j'ai obtenu à partir de git describe :

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

Je suis sur la branche développement. Quand je creuse dans le journal, je vois que les tags les plus récents ne sont pas disponibles sur la branche actuelle :

 $ 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

Dans mon cas, les développeurs ont donc décidé de créer un nouveau fichier libération exclusivement pour le marquage des versions, ce qui a pour conséquence que la branche development n'est plus à jour avec les tags.

J'espère que cela vous aidera et je remercie @eis pour l'idée de vérifier les journaux.

3voto

Haris Dautović Points 636

Très probablement à partir de votre exemple, v1.9 est une balise du commit de fusion.

C'est le comportement attendu de git par défaut et vous pouvez en savoir plus à ce sujet ici : https://git.kernel.org/pub/scm/git/git.git/commit/?id=80dbae03

Pour ignorer les tags de fusion lors de la recherche du plus récent sur la branche courante, vous pouvez utiliser --first-parent option.

git describe --tags --first-parent --abbrev=0

--premier parent

Suivre uniquement le premier commit parent lors d'un commit de fusion. Ceci est utile lorsque vous souhaitez ne pas faire correspondre les balises sur les branches fusionnées dans l'historique du commit cible.

Réf : https://git-scm.com/docs/git-describe

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X