Git
Français ▾ Topics ▾ Latest version ▾ git-shortlog last updated in 2.25.1

NOM

git-shortlog - Résume git log sortie

SYNOPSIS

git shortlog [<options>] [<intervalle de révision>] [[--] <chemin>…​]
git log --pretty=short | git shortlog [<options>]

DESCRIPTION

Récapitule la sortie du « git log » dans un format adapté à l’inclusion dans les annonces de version. Chaque commit sera regroupé par auteur et titre.

En outre, "[PATCH]" sera supprimé de la description de validation.

Si aucune révision n’est passée sur la ligne de commande et que soit l’entrée standard n’est pas un terminal, soit il n’y a pas de branche courante,git shortlog affichera un résumé du journal lu depuis l’entrée standard, sans référence au référentiel courant.

OPTIONS

-n
--numbered

Trier la sortie en fonction du nombre de livraisons par auteur au lieu de l’ordre alphabétique des auteurs.

-s
--summary

Supprimer la description des commits et fournir un résumé du décompte des validations seulement.

-e
--email

Afficher l’adresse courriel de chaque auteur.

--format[=<format>]

Au lieu du sujet du commit, utiliser d’autres informations pour décrire chaque commit. <format>' peut être n’importe quelle chaîne acceptée par l’option ‘--format’ de’git log', telle que'*[%h] %s'. (Voir la section "MISES EN FORME" de git-log[1].)

Chaque commit mis en forme sera reformaté avant d'être affiché.
-c
--committer

Collecter et montrer les identités des validateurs au lieu des auteurs.

-w[<largeur>[,<indent1>[,<indent2>]]]

Formater la sortie en coupant chaque ligne à la longueur largeur. La première ligne de chaque entrée est indentée à indent1 espaces, et la deuxième ligne et les suivantes sont indentées à indent2 espaces. largeur, indent1 et indent2 valent par défaut à 76, 6 et 9 respectivement.

Si la largeur est 0 (zéro) alors indenter les lignes de la sortie sans les recouper.

<plage de révisions>

Afficher uniquement les commits dans la plage de révision spécifiée. Lorsqu’aucune <plage de révision> n’est spécifiée, elle vaut par défaut à HEAD (c’est-à-dire tout l’historique menant au commit actuel). origin.. HEAD spécifie tous les commits accessibles à partir du commit actuel (c’est-à-dire HEAD), mais pas de origin. Pour une liste complète des moyens d’épeler une <plage de révision>, consultez la section « Spécification de plage » de gitrevisions[7].

[--] <chemin>…​

Ne considérer que les commits qui sont suffisants pour expliquer comment les fichiers qui correspondent aux chemins spécifiés ont été créés.

Les chemins peuvent avoir besoin d’être préfixés avec -- pour les séparer des options ou de la plage de révision, en cas de confusion.

TRANSFORMER LES AUTEURS

La fonctionnalité ‘.mailmap’ est utilisée pour regrouper les commits d’une même personne dans le shortlog, où son nom et/ou son adresse email ont été épelés différemment.

Si le fichier .mailmap existe au niveau supérieur du dépôt, ou à l’emplacement indiqué par les options de configuration mailmap.file ou mailmap.blob, il est utilisé pour faire correspondre les noms des auteurs et des validateurs et les adresses e-mail avec les vrais noms canoniques et adresses e-mail.

Dans la forme simple, chaque ligne dans le fichier se compose du nom réel canonique d’un auteur, une espace, et une adresse e-mail utilisée dans le commit (entouré par < et >) en correspondance ue nom. Par exemple :

Nom <commit@email.xx>

Les formes plus complexes sont :

<nom@email.xx> <commit@email.xx>

qui permet à mailmap de remplacer uniquement la partie e-mail d’un commit, et :

Nom <propre@email.xx> <commit@email.xx>

qui permet à mailmap de remplacer à la fois le nom et l’e-mail d’un commit correspondant à l’adresse e-mail de commit spécifiée, et :

Nom Propre <propre@email.xx> Nom dans le Commit <commit@email.xx>

qui permet à mailmap de remplacer à la fois le nom et l’e-mail d’un commit correspondant à la fois au nom et à l’adresse e-mail du commit spécifié.

Exemple 1 : Votre historique contient des commits de deux auteurs, Jane et Joe, dont les noms apparaissent dans le dépôt sous plusieurs formes :

Joe Developer <joe@example.com>
Joe R. Developer <joe@example.com>
Jane Doe <jane@example.com>
Jane Doe <jane@laptop.(none)>
Jane D. <jane@desktop.(none)>

Supposons maintenant que Joe veuille que son deuxième prénom soit utilisé, et que Jane préfère que son nom de famille soit entièrement épelé. Un fichier ‘.mailmap’ approprié ressemblerait à :

Jane Doe         <jane@desktop.(none)>
Joe R. Developer <joe@example.com>

Notez qu’il n’y a pas besoin d’une entrée pour 'jane’laptop.(none), parce que le vrai nom de cet auteur est déjà correct.

Exemple 2 : Votre dépôt contient des commits des auteurs suivants :

nick1 <bugs@compagnie.xx>
nick2 <bugs@compagnie.xx>
nick2 <nick2@compagnie.xx>
santa <me@compagnie.xx>
claus <me@compagnie.xx>
CTO <cto@coompagnie.xx>

Donc, vous voudrez peut-être un fichier .mailmap qui ressemble à :

<cto@company.xx>                       <cto@coompany.xx>
Some Dude <some@dude.xx>         nick1 <bugs@company.xx>
Other Author <other@author.xx>   nick2 <bugs@company.xx>
Other Author <other@author.xx>         <nick2@company.xx>
Santa Claus <santa.claus@northpole.xx> <me@company.xx>

Utilisez un dièse # pour les commentaires qui sont soit sur leur propre ligne, soit après l’adresse e-mail.

GIT

Fait partie de la suite git[1]