afficher toutes les balises dans git log

Pourquoi git log --decoraten'affiche- t-il pas plus d'une balise par commit?

EDIT : Charles Bailey a trouvé la réponse (du moins dans mon cas)
Essentiellement, j'avais une balise qui pointait vers une autre balise qui pointait vers le commit. En raison de cette couche supplémentaire d'indirection, la balise n'apparaissait pas dans le journal. Je vais devoir corriger cela, dépérir en corrigeant notre script de marquage pour taguer correctement, ou par un script shell vaudou pour suivre récursivement les tags. Quoi qu'il en soit, je laisserai cette question juste pour référence au cas où quelqu'un le voudrait. (Je suis nouveau sur le débordement de pile, mais je suppose que c'est le bon protocole?)

... La question originale suit ...

Backstory: Nous utilisons GIT au travail pour le contrôle de code source, et nous avons pour politique de toujours baliser un commit lorsque nous déployons. (C'est en fait un script qui fait des balises, puis extrait la balise sur le serveur). Puisqu'il s'agit d'une application Web avec des serveurs de préparation et de production séparés, nous marquons souvent une version pour la préparation (à des fins de test ou autre), puis nous marquons plus tard le même commit pour la production.

C'est donc très souvent que nous avons plusieurs balises sur le même commit. Ce serait très bien de pouvoir voir cela dans le journal de texte, mais cela ne semble pas le supporter. Je travaille actuellement sur le problème en vérifiant manuellement la balise que je recherche ou en lançant gitk. Bien que ces deux solutions fonctionnent, il me semble que c'est vraiment bizarre git log --decoratede ne prendre en charge qu'une seule balise par commit par défaut.

J'ai fait quelques recherches sur Google, mais je n'ai pas trouvé grand-chose. Est-ce que je rate quelque chose d'évident?

PS (j'utilise en fait une chaîne de format personnalisée avec %d, selon les pages de manuel et quelques tests rapides, c'est équivalent à --decorate)

Note à propos de la balise de la balise (baliser une balise), qui est à l'origine de votre problème, comme l'a correctement souligné Charles Bailey dans le commentaire:

Assurez-vous d'étudier ce fil , car il n'est pas aussi facile de remplacer une balise signée:

• si vous avez déjà poussé une balise, la git tagpage de manuel déconseille sérieusement git tag -f Bde remplacer simplement un nom de balise " A"

• n'essayez pas de recréer une balise signée avec git tag -f(voir l'extrait de fil ci-dessous)

  (il s'agit d'un cas de coin, mais assez instructif sur les balises en général, et cela vient d'un autre contributeur SO Jakub Narębski ):

Veuillez noter que le nom de la balise (balise lourde, c'est-à-dire objet de balise) est stockée à deux endroits:

• dans l'objet tag lui-même en tant que contenu de l'en-tête 'tag' (vous pouvez le voir dans la sortie de " git show <tag>" et aussi dans la sortie de " git cat-file -p <tag>", où <tag>est la balise lourde, par exemple v1.6.3dans le git.gitréférentiel),
• et est également le nom par défaut de la référence de balise (référence dans l' refs/tags/*espace de noms " ") pointant vers un objet de balise.
  Notez que la référence de balise ( référence appropriée dans l' refs/tags/*espace de noms " ") est purement locale ; ce qu'un référentiel a dans « refs/tags/v0.1.3», un autre peut avoir dans « refs/tags/sub/v0.1.3» par exemple.

Ainsi, lorsque vous créez une balise signée ' A', vous avez la situation suivante (en supposant qu'elle pointe vers un commit)

  35805ce   <--- 5b7b4ead  <=== refs/tags/A
  (commit)       tag A
                 (tag)

Veuillez également noter que " git tag -f A A" (notez l'absence d'options le forçant à être une balise annotée) est un noop - cela ne change pas la situation.

Si vous faites " git tag -f -s A A": notez que vous forcez l' écriture d'une balise (donc git suppose que vous savez ce que vous faites), et que l'une des options -s/ -a/ -mest utilisée pour forcer la balise annotée (création de l'objet de balise), vous obtiendrez le situation suivante

  35805ce   <--- 5b7b4ea  <--- ada8ddc  <=== refs/tags/A
  (commit)       tag A         tag A
                 (tag)         (tag)

Notez également que " git show A" afficherait toute la chaîne jusqu'à l'objet sans balise ...

git log --no-walk --tags --pretty="%h %d %s" --decorate=full

Cette version imprimera également le message de validation:

 $ git log --no-walk --tags --pretty="%h %d %s" --decorate=full
3713f3f  (tag: refs/tags/1.0.0, tag: refs/tags/0.6.0, refs/remotes/origin/master, refs/heads/master) SP-144/ISP-177: Updating the package.json with 0.6.0 version and the README.md.
00a3762  (tag: refs/tags/0.5.0) ISP-144/ISP-205: Update logger to save files with optional port number if defined/passed: Version 0.5.0
d8db998  (tag: refs/tags/0.4.2) ISP-141/ISP-184/ISP-187: Fixing the bug when loading the app with Gulp and Grunt for 0.4.2
3652484  (tag: refs/tags/0.4.1) ISP-141/ISP-184: Missing the package.json and README.md updates with the 0.4.1 version
c55eee7  (tag: refs/tags/0.4.0) ISP-141/ISP-184/ISP-187: Updating the README.md file with the latest 1.3.0 version.
6963d0b  (tag: refs/tags/0.3.0) ISP-141/ISP-184: Add support for custom serializers: README update
4afdbbe  (tag: refs/tags/0.2.0) ISP-141/ISP-143/ISP-144: Fixing a bug with the creation of the logs
e1513f1  (tag: refs/tags/0.1.0) ISP-141/ISP-143: Betterr refactoring of the Loggers, no dependencies, self-configuration for missing settings.

Remarque: le commit 5e1361c de brian m. carlson ( bk2204) (pour git 1.9 / 2.0 Q1 2014) traite d'un cas particulier en terme de décoration de log avec des balises:

log: gérer correctement les décorations avec des balises chaînées

git logne gérait pas correctement les décorations lorsqu'un objet de balise faisait référence à un autre objet de balise qui n'était plus une référence, par exemple lorsque la deuxième balise était supprimée .
Le commit ne serait pas décoré correctement car il parse_objectn'avait pas été appelé sur la deuxième balise et par conséquent, son champ balisé n'avait pas été rempli, ce qui n'associait aucune des balises au commit concerné.

Appelez parse_objectpour remplir ce champ s'il est absent afin que la chaîne de balises puisse être déréférencée et que le commit puisse être correctement décoré.
Incluez également des tests pour éviter de futures régressions.

Exemple:

git tag -a tag1 -m tag1 &&
git tag -a tag2 -m tag2 tag1 &&
git tag -d tag1 &&
git commit --amend -m shorter &&
git log --no-walk --tags --pretty="%H %d" --decorate=full