En listant git-ls-remote, pourquoi y a-t-il «^ {}» après le nom du tag?

Lorsque je lance git ls-remote dans l’arborescence, la commande affiche une liste de révisions dans le référentiel d’origine. Pour une raison quelconque, je reçois 2 révisions pour chaque balise et pour la deuxième révision de la même balise, le nom de la balise inclut ^{}

 git ls-remote From [email protected]:andris9/zzzzzz.git d69e66d7c915b9682618b7f304b80cc0ae4c7809 HEAD .... bb944682f7f65272137de74ed18605e49257356c refs/tags/v0.1.6 771a930dc0ba86769d6862bc4dc100acc50170fa refs/tags/v0.1.6^{} a72251d945353a360087eb78ee75287c38a1c0e6 refs/tags/v0.1.7 d69e66d7c915b9682618b7f304b80cc0ae4c7809 refs/tags/v0.1.7^{} 

Je crée des tags avec

 git tag -a v0.1.8 -m "tag message" git push --tags 

D’après les exemples de la page de manuel git-ls-remote , il n’y a pas de balises en double, alors peut-être que je fais quelque chose de mal?

Il existe 2 types de tags – lightweight et annotated . Les balises légères ne sont que des réfs qui pointent sur un object alors que les balises annotées sont un object git distinct et stockent beaucoup plus d’informations comme auteur, committer, un message de validation, etc.

Lorsque vous avez utilisé git tag -a pour créer une balise, git aurait créé une balise annotée pour vous.

Le ^{} est la syntaxe utilisée pour déréférencer une balise. Il est décrit dans gitrevisions .

  • Lorsqu’il est utilisé avec des objects tag, git déréférencera récursivement la balise jusqu’à ce qu’il trouve un object non-tag.

  • Utilisé avec des objects non-tag, il ne fait rien et équivaut à ignorer le ^{}

La refs/tags/v0.1.6 dans votre référentiel pointe vers l’object tag bb944682f7f65272137de74ed18605e49257356c , qui à son tour pointe sur 771a930dc0ba86769d6862bc4dc100acc50170fa (object non-tag) que je suppose en train de stocker les informations de validation.

Donc, quand vous faites des refs/tags/v0.1.6^{} , git va déréférencer la balise et la résoudre en 771a930dc0ba86769d6862bc4dc100acc50170fa – l’object non-tag.

Il y a aussi une commande git show-ref qui peut être utilisée pour lister uniquement les balises, et éventuellement dereference comme suit, et dans votre cas, devrait produire la sortie suivante:

 $ git show-ref --tags bb944682f7f65272137de74ed18605e49257356c refs/tags/v0.1.6 a72251d945353a360087eb78ee75287c38a1c0e6 refs/tags/v0.1.7 $ git show-ref --tags --dereference bb944682f7f65272137de74ed18605e49257356c refs/tags/v0.1.6 771a930dc0ba86769d6862bc4dc100acc50170fa refs/tags/v0.1.6^{} a72251d945353a360087eb78ee75287c38a1c0e6 refs/tags/v0.1.7 d69e66d7c915b9682618b7f304b80cc0ae4c7809 refs/tags/v0.1.7^{} 

Pour confirmer cela, vous pouvez utiliser la commande git show pour vous donner plus de détails sur l’object git.

Ceci est l’information de l’un de mes référentiels git de test.

 $ git show 43f9a98886ba873c0468c608f24c408b9991414f tag v0.1 Tagger: Ash  Date: Sun Jul 15 00:14:43 2012 -0700 Tagging Stable repo 0.1 :) -----BEGIN PGP SIGNATURE-----  -----END PGP SIGNATURE----- commit e55df25f2321a6b2c9a02fa80ccba7cbe3c38c08 Merge: 796efcd 58e3a4d Author: Ash  Date: Sun Jul 15 00:02:44 2012 -0700 Merge branch 'dev' into 'master' for stable 0.1. $ git show e55df25f2321a6b2c9a02fa80ccba7cbe3c38c08 commit e55df25f2321a6b2c9a02fa80ccba7cbe3c38c08 Merge: 796efcd 58e3a4d Author: Ash  Date: Sun Jul 15 00:02:44 2012 -0700 Merge branch 'dev' into 'master' for stable 0.1.