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

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.

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.

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 .

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

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

Dernier message de balise uniquement:

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

Utiliser l'option --format

git tag -l --format='%(tag) %(subject)'

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.