Comment lister toutes les balises avec le message complet dans git?


361

Je veux que git liste toutes les balises avec l'annotation complète ou le message de validation. Quelque chose comme ça est proche:

git tag -n5

Cela fait exactement ce que je veux, sauf qu'il n'apparaîtra que sur les 5 premières lignes du message de balise.

Je suppose que je peux simplement utiliser un très grand nombre. Quel est le nombre le plus élevé que je peux utiliser ici? Est-ce la même chose sur tous les ordinateurs?

MISE À JOUR : J'ai eu beaucoup de temps pour y réfléchir, et maintenant je pense que je ne veux pas nécessairement montrer l'intégralité de chaque message si certains d'entre eux sont extraordinairement longs. Je n'avais pas vraiment de besoin particulier qui m'obligeait à voir des messages massifs (à part ma propre propension à être de longue haleine dans tout ce que j'écris, y compris les messages de balise). Je n'aimais tout simplement pas l'idée que cela n'allait pas nécessairement me montrer tout le message, car cela me donnait l'impression de me cacher des informations. Mais trop d'informations peuvent aussi être une mauvaise chose.


62
git tag -nl'a fait pour moi
Martin Berger

11
git tag -nimprime uniquement la première ligne de l'annotation, selon la page de manuel.
Paul Price

@INTPner, convenu, la balise -l est utilisée pour répertorier les balises avec un modèle spécifique. Modification de la réponse.
Zubair

Réponses:


350

Essayez ceci, il répertoriera toutes les balises avec des annotations et 9 lignes de message pour chaque balise:

git tag -n9

peut également utiliser

git tag -l -n9

si des balises spécifiques doivent être répertoriées:

git tag -l -n9 v3.*

(par exemple, la commande ci-dessus n'affichera que les balises commençant par "v3".)

-l, --list Liste les balises avec des noms qui correspondent au modèle donné (ou tous si aucun modèle n'est donné). L'exécution de "git tag" sans arguments répertorie également toutes les balises. Le modèle est un caractère générique du shell (c'est-à-dire, apparié à l'aide de fnmatch (3)). Plusieurs modèles peuvent être donnés; si l'un d'eux correspond, la balise est affichée.


6
Cela n'imprimera que la première ligne de chaque annotation.
Paul Price

3
@Paul Price: vous seul avez une annotation, sinon il imprime le message de validation. D'accord, ce n'est pas la réponse.
Ciro Santilli 郝海东 冠状 病 六四 事件 法轮功

3
Selon la documentation, l' -loption est de filtrer sur un motif. Je ne vois pas en quoi cela serait utile ici. Suis-je en train de manquer quelque chose?
still_dreaming_1

2
@INTPnerd oui, -lc'est totalement superflu ici
Lambart

1
@ P.MyerNore Vous devez utiliser une version bizarre de git ou passer des arguments supplémentaires pour faire quelque chose de plus que ce que cette question demande. Mais il est bon de savoir que pour certaines situations, le -l est nécessaire.
still_dreaming_1

119
git tag -n99

Court et doux. Cela répertoriera jusqu'à 99 lignes de chaque message d'annotation / de validation de balise. Voici un lien vers la documentation officielle de git tag .

Je pense maintenant que la limitation d'afficher jusqu'à 99 lignes par étiquette est en fait une bonne chose car la plupart du temps, s'il y avait vraiment plus de 99 lignes pour une seule étiquette, vous ne voudriez pas vraiment voir tout le reste de les lignes voudriez-vous? Si vous vouliez voir plus de 99 lignes par étiquette, vous pouvez toujours l'augmenter à un plus grand nombre.

Je veux dire, je suppose qu'il pourrait y avoir une situation spécifique ou une raison de vouloir voir des messages de balises massifs, mais à quel moment ne voulez-vous pas voir le message entier? Quand il a plus de 999 lignes? 10 000? 1 000 000? Mon point est, il est généralement logique d'avoir un plafond sur le nombre de lignes que vous verriez, et ce nombre vous permet de définir cela.

Puisque je fais un argument pour ce que vous voulez généralement voir en regardant vos balises, il est probablement logique de définir quelque chose comme ça comme un alias (d'après le commentaire d'Iulian Onofrei ci-dessous):

git config --global alias.tags 'tag -n99'

Je veux dire, vous ne voulez pas vraiment avoir à taper git tag -n99chaque fois que vous voulez juste voir vos tags , n'est-ce pas ? Une fois cet alias configuré, chaque fois que vous voulez voir vos balises, il vous suffit de taper git tagsdans votre terminal. Personnellement, je préfère aller plus loin et créer des alias bash encore plus abrégés pour toutes mes commandes couramment utilisées. À cette fin, vous pouvez ajouter quelque chose comme ceci à votre fichier .bashrc (fonctionne sur Linux et environnements similaires):

alias gtag='git tag -n99'

Ensuite, chaque fois que vous voulez voir vos tags, il vous suffit de taper gtag. Un autre avantage de descendre le chemin d'alias (alias git ou alias bash ou autre) est que vous avez maintenant un endroit déjà en place où vous pouvez ajouter d'autres personnalisations à la façon dont vous personnellement, voulez généralement que vos balises vous soient montrées (comme le tri de certaines façons comme dans mon commentaire ci-dessous, etc.). Une fois que vous aurez surmonté le problème de la création de votre premier alias, vous réaliserez à quel point il est facile d'en créer plus pour d'autres choses que vous aimez travailler de manière personnalisée, comme git log, mais gardons-le pour une autre question / réponse .


3
git config --global alias.tags 'tag -n99'
Iulian Onofrei

@IulianOnofrei, sympa, je ne savais pas que git vous permettait de définir des alias. Je me rends compte que c'est hors sujet, mais je ne peux pas résister. Voici ce que j'utilise maintenant (placé dans votre .bashrc ou quelque chose comme ça):alias gtag='git for-each-ref --format="%(refname:short) %(taggerdate) %(subject) %(body)" refs/tags | sort -V'
still_dreaming_1

25

La réponse de Mark Longair (en utilisant git show) est proche de ce qui est souhaité dans la question. Cependant, il inclut également la validation pointée par la balise, ainsi que le patch complet pour cette validation. Étant donné que la validation peut être quelque peu indépendante de la balise (ce n'est qu'une seule validation que la balise tente de capturer), cela peut être indésirable. Je pense que ce qui suit est un peu plus agréable:

for t in `git tag -l`; do git cat-file -p `git rev-parse $t`; done

Le git show de Mark n'a pas montré de correctifs pour mon utilisation. Sa commande omet -p ou --patch, mais pour être totalement sûr de sauter le diff, on peut utiliser: --no-patch. (sur git v2.7.1 / mac)
AnneTheAgile

13

C'est loin d'être joli, mais vous pouvez créer un script ou un alias qui fait quelque chose comme ça:

for c in $(git for-each-ref refs/tags/ --format='%(refname)'); do echo $c; git show --quiet "$c"; echo; done

Y at - il une raison de ne pas remplacer git for-each-ref refs/tags/ --format='%(refname)'avec git tag -l?
Shai Berger

@ShaiBerger: dans la pratique, je ne pense pas - je suppose que je pensais juste que git tagc'est de la porcelaine et de la git for-each-refplomberie, donc la sortie de ce dernier devrait être plus stable pour les scripts.
Mark Longair

10

Dernier message de balise uniquement:

git cat-file -p $(git rev-parse $(git tag -l | tail -n1)) | tail -n +6

2
Pour toute autre personne qui passe par Google: Si vous souhaitez afficher le message d'une balise particulière: git cat-file -p <tag> | tail -n +6
Kit Peters


2

Je préfère le faire sur la ligne de commande, mais si cela ne vous dérange pas une interface Web et que vous utilisez GitHub, vous pouvez visiter https://github.com/user/repo/tagset cliquer sur le "..." à côté de chaque balise pour afficher son annotation.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.