afficher tous les tags dans le journal git

Question

Pourquoi est-ce que git log --decorate ne pas afficher plus d'un tag 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. À cause de cette couche supplémentaire d'indirection, le tag n'apparaissait pas dans le journal. Je vais devoir résoudre ce problème, soit en corrigeant notre script de balisage pour qu'il soit correct, soit en utilisant le voodoo du shell script pour suivre récursivement les balises. Quoi qu'il en soit, je vais laisser cette question juste pour référence au cas où quelqu'un la voudrait. (Je suis nouveau sur stack overflow, mais je suppose que c'est le protocole correct ?)

... La question originale suit ...

Backstory : Nous utilisons GIT au travail pour le contrôle de la source, et nous avons une politique de toujours marquer un commit lorsque nous déployons. (C'est en fait un script qui fait les tags, et ensuite tire le tag sur le serveur). Comme il s'agit d'une application web avec des serveurs de mise en scène et de production séparés, nous marquons souvent une version pour la mise en scène (pour les tests ou autre), puis plus tard, nous marquons le même commit pour la production.

Il est donc très fréquent que nous ayons plusieurs balises sur le même commit. Ce serait très bien de pouvoir voir cela dans le journal de texte, mais il ne semble pas le supporter. Je contourne actuellement le problème en vérifiant manuellement la balise que je recherche, ou en lançant la fonction gitk . Bien que ces deux solutions fonctionnent, il me semble que c'est vraiment bizarre pour git log --decorate pour ne supporter qu'un seul tag par commit par défaut.

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

P.S. (J'utilise en fait une chaîne de format personnalisée avec %d d'après les pages du manuel et quelques tests rapides, il est équivalent à --decorate )

Answer 1

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.

Answer 2

Note sur le tag of tag (le marquage d'un tag), qui est à l'origine de votre problème, en tant que Charles Bailey correctement souligné 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 étiquette, le git tag page de manuel sérieusement déconseillé un simple git tag -f B pour remplacer un nom de balise " A "

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

  (il s'agit d'un cas particulier, mais assez instructif sur les balises en général, et il provient d'un autre contributeur de l'OS. Jakub Narebski ) :

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

• dans l'objet tag lui-même comme 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 une étiquette de poids lourd, par exemple v1.6.3 en git.git dépôt),
• et aussi le nom par défaut de la référence de la balise (référence en " refs/tags/* (" namespace ") pointant vers un objet balise.
  Notez que la balise référence (référence appropriée dans le " refs/tags/* ") est purement local Ce qu'un dépôt a en refs/tags/v0.1.3 ', d'autres peuvent avoir en ' 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'il pointe vers un commit)

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

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

Si vous faites " git tag -f -s A A " : notez que vous force owerwriting a tag (donc git suppose que vous savez ce que vous faites), et que l'un des éléments suivants est utilisé -s / -a / -m est utilisée pour forcer une balise annotée (création de l'objet balise), vous obtiendrez la situation suivante

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

Notez également que " git show A "montrerait toute la chaîne jusqu'à l'objet non étiqueté...

Answer 3

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

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

git log ne gérait pas correctement les décorations lorsqu'un objet balise faisait référence à un autre objet 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 parse_object n'avait pas été appelé sur la deuxième balise et donc son champ balise n'avait pas été rempli, ce qui fait qu'aucune des balises n'était associée au commit correspondant.

Appelez parse_object pour 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 les régressions futures.

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

Answer 4

Remarque : je ne traite que de la sujet de la question :

afficher tous les tags dans le journal git

... no les détails spécifiques de la question.

Montrer l'intégralité git log (en couleur !) pour chaque livraison étiquetée :

Je pense vraiment que c'est la forme la plus utile et la plus belle :

git log --no-walk --tags

Il montre l'intégralité git log pour chaque livraison qui a une étiquette attachée. C'est très pratique !

Et si vous souhaitez filtrer uniquement les balises qui correspondent à un certain modèle de recherche, procédez comme suit :

git log --no-walk --tags=*some_string*

Exemple :

git log --no-walk --tags=*release/my_board*

Afficher une ligne git log résumé (en couleur !) pour chaque commit tagué :

Si vous voulez juste voir une ligne par commit tagué, faites ceci à la place. Note : ceci est modifié par rapport à La belle de Coderwall git lg alias :

git log --color --no-walk --tags --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit

Et bien sûr, vous pouvez toujours filtrer sur les balises que vous souhaitez en utilisant la fonction --tags=*some_string* à la place :

git log --color --no-walk --tags=*some_string* --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit

Exemple :

git log --color --no-walk --tags=*release/my_board* --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit

Références :

1. El réponse de @Marcello de Sales m'a aidé à démarrer.
2. La belle de Coderwall git lg alias