Setup and Config
Getting and Creating Projects
Basic Snapshotting
Branching and Merging
Sharing and Updating Projects
Inspection and Comparison
Patching
Debugging
External Systems
Server Admin
Guides
- gitattributes
- Command-line interface conventions
- Everyday Git
- Frequently Asked Questions (FAQ)
- Glossary
- Hooks
- gitignore
- gitmodules
- Revisions
- Submodules
- Tutorial
- Workflows
- All guides...
Administration
Plumbing Commands
- 2.45.1 → 2.47.1 no changes
- 2.45.0 04/29/24
- 2.43.3 → 2.44.2 no changes
- 2.43.2 02/13/24
- 2.43.1 no changes
- 2.43.0 11/20/23
- 2.42.1 → 2.42.3 no changes
- 2.42.0 08/21/23
- 2.41.1 → 2.41.2 no changes
- 2.41.0 06/01/23
- 2.40.1 → 2.40.3 no changes
- 2.40.0 03/12/23
- 2.39.1 → 2.39.5 no changes
- 2.39.0 12/12/22
- 2.38.1 → 2.38.5 no changes
- 2.38.0 10/02/22
- 2.37.1 → 2.37.7 no changes
- 2.37.0 06/27/22
- 2.36.1 → 2.36.6 no changes
- 2.36.0 04/18/22
- 2.35.1 → 2.35.8 no changes
- 2.35.0 01/24/22
- 2.33.3 → 2.34.8 no changes
- 2.33.2 03/23/22
- 2.33.1 10/12/21
- 2.33.0 08/16/21
- 2.32.1 → 2.32.7 no changes
- 2.32.0 06/06/21
- 2.31.1 → 2.31.8 no changes
- 2.31.0 03/15/21
- 2.30.1 → 2.30.9 no changes
- 2.30.0 12/27/20
- 2.29.1 → 2.29.3 no changes
- 2.29.0 10/19/20
- 2.27.1 → 2.28.1 no changes
- 2.27.0 06/01/20
- 2.25.1 → 2.26.3 no changes
- 2.25.0 01/13/20
- 2.18.1 → 2.24.4 no changes
- 2.18.0 06/21/18
- 2.13.7 → 2.17.6 no changes
- 2.12.5 09/22/17
- 2.1.4 → 2.11.4 no changes
- 2.0.5 12/17/14
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 dépôt actuel.
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
-
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é.
- --date=<format>
-
Affiche les dates formatées en fonction de la chaîne de date donnée. (Voir l’option
--date
dans la section "Formatage de commit" de git-log[1]). Utile avec--group=format:<format>
. - --group=<type>
-
Grouper les commits basés sur
<type>
. Si aucune option--group
n’est spécifiée, la valeur par défaut estauthor
.<type>
peut être :-
author
, les commits sont groupés par auteur -
committer
, les commits sont groupés par validateur (équivalent à-c
) -
trailer:<field>
, Le champ<field>
est interprété comme un message de fin de commit sans prise en compte de la casse (voir git-interpret-trailers[1]). Par exemple, si votre projet utilise des fins de messagesReviewed-by
, vous voulez sans doute voir qui a fait des revisions avecgit shortlog -ns --group=trailer:reviewed-by
. -
format:<format>
, toute chaîne acceptée par l’option--format
de git log (voir la section "MISES EN FORME DIFF" de git-log[1]).Notez que les commits qui n’incluent pas de fin de message ne seront pas comptés. De la même façon, les commits avec plusieurs fins de message (par ex., plusieurs approbations) peuvent être comptés plus d’une fois (mais seulement une fois par valeur unique de fin de message sur ce commit).
Shortlog tentera d’analyser chaque valeur de fin de texte comme une identité "nom <email>". En cas de succès, la carte de courrier est appliquée et le courriel est omis à moins que l’option
--email
ne soit spécifiée. Si la valeur ne peut pas être analysée comme une identité, elle sera prise littéralement et complètement.
Si
--group
est spécifié plusieurs fois, les commit sont comptés sous chaque valeur (mais encore une fois, une seule fois par valeur unique dans ce commit). Par exemple,git shortlog --group=author --group=trailer:co-authored-by
compte à la fois les auteurs et les co-auteurs. -
- -c
- --committer
-
Il s’agit d’un alias pour
--group=committer
. - -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
etindent2
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-à-direHEAD
), mais pas deorigin
. 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.
Limitation de commit
En plus de spécifier une plage de commits qui doivent être listés en utilisant les notations spéciales expliquées dans la description, des limitations supplémentaires de commits peuvent être appliquées.
L’utilisation d’un plus grand nombre d’options filtre généralement plus la sortie (par exemple --since=<date1>
limite aux commits plus récents que <date1>
, et son utilisation avec --grep=<motif>
limite aux commits dont le message de journal a une ligne qui correspond <motif>
), sauf indication contraire.
Notez que celles-ci sont appliquées avant les options de classement et de formatage des commits, telles que --reverse
.
- -<nombre>
- -n <nombre>
- --max-count==<nombre>
-
Limite le nombre de commits dans la sortie.
- --skip=<nombre>
-
Sauter’nombre' commits avant de commencer à afficher la sortie de journal.
- --since=<date>
- --after=<date>
-
Afficher les commits plus récents qu’une date spécifique.
- --since-as-filter=<date>
-
Afficher tous les commits plus récents qu’une date spécifique. Cela visite tous les commits dans la plage, plutôt que de s’arrêter au premier commit qui est plus ancien qu’une date spécifique.
- --until=<date>
- --before=<date>
-
Afficher les commits plus anciens qu’une date spécifique.
- --author=<motif>
- --committer=<motif>
-
Limiter la sortie des commits à ceux dont les lignes d’en-tête auteur/validateur correspondent au motif spécifié (expression régulière). Avec plus d’un
--author=<motif>
, les commits dont l’auteur correspond à l’un des motifs donnés sont choisis (de même pour plusieurs--committer=<motif>
). - --grep-reflog=<motif>
-
Limiter la sortie des commits à ceux dont les entrées de reflog correspondent au motif spécifié (expression régulière). Avec plus d’un
--grep-reflog
, les commits dont le message de reflog correspond à l’un des modèles donnés sont choisis. C’est une erreur d’utiliser cette option à moins que--walk-reflogs
ne soit utilisé. - --grep=<motif>
-
Limiter la sortie des commits à ceux dont un message de validation correspond au motif spécifié (expression régulière). Avec plus d’un
--grep=<motif>
, les commits dont le message correspond à l’un des motifs donnés sont choisis (mais voir--all-match
).Lorsque
--notes
est en vigueur, le message des notes est vérifié comme s’il faisait partie du message du journal. - --all-match
-
Limiter la sortie des commits à ceux qui correspondent à la fois à tous les
--grep
donnés, au lieu de ceux qui correspondent à au moins un. - --invert-grep
-
Limiter la sortie des commits à ceux dont un message de validation ne correspond pas au motif spécifié avec
--grep=<motif>
. - -i
- --regexp-ignore-case
-
Faites correspondre les expressions régulières sans tenir compte de la casse des lettres.
- --basic-regexp
-
Considérer les motifs limitatifs comme des expressions régulières de base ; c’est la valeur par défaut.
- -E
- --extended-regexp
-
Considérer les motifs limitatifs comme des expressions régulières étendues au lieu des expressions régulières par défaut de base.
- -F
- --fixed-strings
-
Considérer les motifs limitatifs comme des chaînes de caractères fixes (ne pas interpréter le motif comme une expression régulière).
- -P
- --perl-regexp
-
Considérer les motifs limitatifs comme des expressions régulières compatibles Perl.
La prise en charge de ces types d’expressions régulières est une dépendance optionnelle à la compilation. Si Git n’a pas été compilé avec ce support et que cette option est activée, la commande se termine immédiatement.
- --remove-empty
-
Arrêter lorsqu’un chemin donné disparaît de l’arbre.
- --merges
-
N’afficher que les commits de fusion. C’est exactement la même chose que
--min-parents=2
. - --no-merges
-
Ne pas afficher les commits avec plus d’un parent. C’est exactement la même chose que
--max-parents=1
. - --min-parents=<nombre>
- --max-parents=<nombre>
- --no-min-parents
- --no-max-parents
-
Afficher uniquement les commits qui ont au moins (ou au plus) autant de commits parents. En particulier,
--max-parents=1
est la même chose que--no-merges
,--min-parents=2
est la même chose que--merges
.--max-parents=0
donne tous les commits racine et--min-parents=3
toutes les fusions octopus.--no-min-parents
et--no-max-parents
réinitialisent ces limites (à sans limite). Les formes équivalentes sont--min-parents=0
(tout commit a 0 ou plus de parents) et--max-parents=-1
(les nombres négatifs dénotent l’absence de limite supérieure). - --first-parent
-
Lors de la recherche de commits à inclure, ne suivre que le premier commit parent lors d’un commit de fusion. Cette option peut donner une meilleure vue d’ensemble lors de l’affichage de l’évolution d’une branche de sujet particulière, parce que la fusion dans une branche de sujet a tendance à n’être que des mises à jour avec l’amont de temps en temps, et cette option permet d’ignorer les commits individuels apportés dans votre historique par de telles fusions.
- --exclude-first-parent-only
-
Lors de la recherche de commits à exclure (avec un ^ ;), ne suivre que le premier commit parent lorsqu’un commit de fusion est vu. Cela peut être utilisé pour trouver l’ensemble des changements dans une branche de sujet à partir du point où elle a divergé de la branche distante, étant donné que des fusions arbitraires peuvent être des changements de branches thématiques valides.
- --not
-
Inverse le sens du préfixe ^ (ou son absence) pour tous les spécificateurs de révision suivants, jusqu’au prochain
--not
. Lorsqu’il est utilisé sur la ligne de commande avant --stdin, les révisions passées par stdin ne seront pas affectées. Inversement, lorsqu’il est passé par l’entrée standard, les révisions passées sur la ligne de commande ne seront pas affectées. - --all
-
Faire comme si toutes les refs de
refs/
, ainsi queHEAD
, étaient listées sur la ligne de commande comme'<commit>'. - --branches[=<motif>]
-
Faire comme si toutes les refs de
refs/heads
étaient listées sur la ligne de commande comme'<commit>'. Si'<motif>' est fournir, limiter les branches à celles qui correspondent à un glob shell donné. Si le motif ne présente pas de ?, *, ni [, /* à la fin est implicite. - --tags[=<motif>]
-
Faire comme si toutes les refs de
refs/tags
étaient listées sur la ligne de commande comme'<commit>'. Si'<motif>' est fournir, limiter les étiquettes à celles qui correspondent à un glob shell donné. Si le motif ne présente pas de ?, *, ni [, /* à la fin est implicite. - --remotes[=<motif>]
-
Faire comme si toutes les refs de ‘refs/remotes’ étaient listées sur la ligne de commande comme'<commit>'. Si'<motif>' est donné, limiter les branches de suivi à distance à celles qui correspondent à un glob shell donné. Si le motif ne présent pas ?, *, ni [, /* à la fin est implicite.
- --glob=<motif-glob>
-
Faire comme si toutes les réfs correspondant au shell glob'<motif-glob>' étaient listées sur la ligne de commande comme'<commit>'. Le préfixe refs/, est automatiquement ajouté s’il n’y en a pas. Si le motif ne présente pas de ?, *, ni [, /* à la fin est implicite.
- --exclude=<motif-glob>
-
Ne pas inclure les références correspondant à'<glob-pattern>' que les
--all
,--branches
,--tags
,--remotes
, ou--glob
suivantes considéreraient autrement. Les répétitions de cette option accumulent les motifs d’exclusion jusqu’à la prochaine option--all
,--branches
,--tags
,--remotes
ou--glob
(les autres options ou arguments n’éliminent pas les motifs accumulés).Les motifs donnés ne doivent pas commencer par
refs/heads
,refs/tags
, ourefs/remotes
lorsqu’ils sont appliqués à--branches
,--tags
, ou--remotes
, respectivement, et ils doivent commencer parrefs/
lorsqu’ils sont appliqués à--glob
ou--all
. Si un'/*' final est intentionnel, il doit être donné explicitement. -
Ne pas inclure les références qui seraient cachées par
git-fetch
,git-receive-pack
ougit-upload-pack
en consultant la configurationfetch.hideRefs
,receive.hideRefs
ouuploadpack.hideRefs`correspondante ainsi que `transfer.hideRefs
(voir git-config[1]). Cette option affecte l’option de pseudo-référence suivante--all
ou--glob
et est effacée après leur traitement. - --reflog
-
Faire comme si tous les objets mentionnés par les reflogs étaient listés sur la ligne de commande comme
<commit>
. - --alternate-refs
-
Faire comme si tous les objets mentionnés en tant que sommets de référence des dépôts alternatifs étaient listés sur la ligne de commande. Un dépôt alternatif est tout dépôt dont le répertoire d’objets est spécifié dans
objects/info/alternates
. L’ensemble des objets inclus peut être modifié parcore.alternateRefsCommand
, etc. Voir git-config[1]. - --single-worktree
-
Par défaut, tous les arbres de travail seront examinés par les options suivantes lorsqu’il y en a plusieurs (voir git-worktree[1]) :
--all
,--reflog
et--indexed-objects
. Cette option les oblige à n’examiner que l’arbre de travail actuel. - --ignore-missing
-
En voyant un nom d’objet invalide dans l’entrée, faire comme si la mauvaise entrée n’avait pas été donnée.
- --bisect
-
Faire comme si le mauvais bissection ref
refs/bisect/bad
a été inscrite comme si elle a été suivie par--not
et que les bonnes refs de bissectionrefs/bisect/good-*
sur la ligne de commande. - --stdin
-
En plus d’obtenir des arguments de la ligne de commande, les lire aussi depuis l’entrée standard. Cela accepte des commits et des pseudo-options comme
--all
et--glob=
. Lorsqu’un séparateur--
est vu, les entrées suivantes sont traitées comme des chemins et utilisées pour limiter le résultat. Les drapeaux comme--not
qui sont lus via l’entrée standard ne sont respectés que pour les arguments passés de la même manière et n’influenceront aucun argument de ligne de commande suivant. - --cherry-mark
-
Comme
--cherry-pick
(voir ci-dessous) mais marquer les commits équivalents avec==
plutôt que de les omettre, et les différents avec+
. - --cherry-pick
-
Omettre tout commit qui introduit le même changement qu’un autre commit de l'"autre côté" lorsque l’ensemble des commits est limité avec une différence symétrique.
Par exemple, si vous avez deux branches,
A
etB
, une façon habituelle de lister tous les commits d’un seul côté d’entre elles est avec--left-right
(voir l’exemple ci-dessous dans la description de l’option--left-right
). Cependant, cela montre les commits qui ont été picorés sur l’autre branche (par exemple, “3rd on b” peut être trié sur la branche A). Avec cette option, ces paires de commits sont exclues de la sortie. - --left-only
- --right-only
-
Ne lister que les commits du côté respectif d’une différence symétrique, c’est-à-dire seulement ceux qui seraient marqués
<
resp.>
par--left-right
.Par exemple,
--cherry-pick --right-only A...B
omet les commits deB
qui sont dansA
ou sont équivalents en rustine à un commit enA
. En d’autres termes, cela liste les commits+
degit cherry A B
. Plus précisément,--cherry-pick --right-only --no-merges
donne la liste exacte. - --cherry
-
Un synonyme pour
--right-only --cherry-mark --no-merges
; utile pour limiter la sortie aux commits de notre côté et marquer ceux qui ont été appliqués de l’autre côté d’un historique en fourche avecgit log --cherry amont...mabranche', similaire à `git cherry upstream mabranche
. - -g
- --walk-reflogs
-
Au lieu de marcher dans la chaîne des commits ancêtres, parcourir les entrées de reflog du plus récent au plus ancien. Lorsque cette option est utilisée, vous ne pouvez pas spécifier de commits à exclure (c’est-à-dire que les notations ^commit, commit1..commit2 et’commit1...commit2' ne peuvent pas être utilisées).
Avec un format
--pretty
autre queonline
etreference
(pour des raisons évidentes), cela fait que la sortie a deux lignes supplémentaires d’informations tirées du reflog. L’indicateur de reflog dans la sortie peut être affiché commeref@{<Nième>}
(où <Nième> est l’index chronologique inverse dans le reflog) ou commeref@{<horodatage>}
(avec l'<horodatage> pour cette entrée), selon quelques règles :-
Si le point de départ est spécifié comme
ref@{<Nième>}
, afficher le format de l’index. -
Si le point de départ a été spécifié comme
ref@{now}
, afficher le format de l’horodatage. -
Si ni l’un ni l’autre n’a été utilisé, mais que
--date' a été donné sur la ligne de commande, afficher l'horodatage dans le format demandé par `--date
. -
Sinon, afficher le format de l’index.
Sous
--pretty=oneline
, le message de commit est préfixé avec cette information sur la même ligne. Cette option ne peut pas être combinée avec--reverse
. Voir aussi git-reflog[1].Sous l’option
--pretty=reference
, ces informations ne seront pas affichées du tout. -
- --merge
-
Afficher les commits touchant les chemins conflictuels dans la plage
HEAD... <autre>
, où<autre>
est la première pseudo-ref existante dansMERGE_HEAD
,CHERRY_PICK_HEAD
,REVERT_HEAD
ouREBASE_HEAD
. Fonctionne seulement lorsque l’index a des entrées non fusionnées. Cette option peut être utilisée pour montrer les commits pertinents lors de la résolution des conflits à partir d’une fusion à 3 voies. - --boundary
-
Afficher les commits de limite exclus. Les limites sont préfixées par
-
.
Simplification de l’historique
Parfois vous n’êtes intéressé que par certaines parties de l’historique, par exemple les commits qui modifient un <chemin> particulier. Mais il y a deux parties dans la Simplification de l’historique, une partie est la sélection des commits et l’autre la manière de le faire, car il existe différentes stratégies pour simplifier l’historique.
Les options suivantes sélectionnent les commits à afficher :
Notez que des commits supplémentaires peuvent être affichés pour donner un historique significatif.
Les options suivantes influent sur la façon dont la simplification est effectuée :
- Mode par défaut
-
Simplifie l’historique jusqu’à l’historique le plus simple en expliquant l’état final de l’arbre. Le plus simple parce qu’il taille certaines branches latérales si le résultat final est le même (c’est-à-dire qu’il fusionne des branches avec le même contenu)
- --show-pulls
-
Inclure tous les commits du mode par défaut, mais aussi tous les commits de fusion qui ne sont pas MEMEARBRE au premier parent mais qui sont MEMEARBRE à un parent ultérieur. Ce mode est utile pour montrer les commits de fusion qui ont "introduit en premier" une modification dans une branche.
- --full-history
-
Identique au mode par défaut, mais ne pas élaguer l’historique.
- --dense
-
Seuls les commits sélectionnés sont affichés, plus certains pour avoir un historique significatif.
- --sparse
-
Tous les commits de l’historique simplifié sont affichés.
- --simplify-merges
-
Option supplémentaire à
--full-history
pour supprimer certaines fusions inutiles de l’historique résultant, car il n’y a pas de commits sélectionnés contribuant à cette fusion. - --ancestry-path[=<commit>]
-
Lorsque l’on donne une plage de commits à afficher (par exemple commit1..commit2 ou commit2 ^commit1), n’afficher que les commits de cette plage qui sont des ancêtres de <commit>, des descendants de <commit>, ou <commit> lui-même. Si aucun commit n’est spécifié, utiliser commit1 (la partie exclue de la plage) comme <commit>. Peut être passée plusieurs fois ; si c’est le cas, un commit est inclus s’il est l’un des commits donnés ou s’il est un ancêtre ou un descendant de l’un d’eux.
Une explication plus détaillée suit.
Supposons que vous ayez spécifié foo
pour <chemins>. Nous appellerons les commits qui modifient foo
!MEMEARBRE, et le reste MEMEARBRE. (Dans un diff filtré pour foo
, ils sont différents et égaux, respectivement.)
Dans ce qui suit, nous nous référerons toujours au même exemple d’historique pour illustrer les différences entre les paramètres de simplification. Nous supposons que vous filtrez pour un fichier foo
dans ce graphe de commits :
.-A---M---N---O---P---Q / / / / / / I B C D E Y \ / / / / / `-------------' X
La ligne horizontale de l’historique A---Q est prise pour être le premier parent de chaque fusion. Les commits sont :
-
I
est le commit initial, dans lequel foo` existe avec le contenu ''asdf', et un fichierquux
existe avec le contenu 'quux'. Les commits initiaux sont comparés à un arbre vide, doncI
est !MEMEARBRE. -
Dans
A
,foo
ne contient que “foo”. -
B
contient le même changement queA
. Sa fusionM
est triviale et donc MEMEARBRE pour tous les parents. -
C
ne change pasfoo
, mais sa fusionN
le change en “foobar”, donc ce n’est pas MEMEARBRE à aucun parent. -
D
metfoo
surbaz
. Sa fusionO
combine les chaînes de caractères deN
etD
à “foobarbaz” ; c’est-à-dire qu’elle n’est pas MEMEARBRE à aucun parent. -
E
changequux
en “xyzzy”, et sa fusionP
combine les chaînes en “quux xyzzy”.P
est MEMEARBRE àO
, mais pas àE
. -
X
est un commit racine indépendant qui a ajouté un nouveau fichierside
, etY
l’a modifié.Y
est MEMEARBRE àX
. Sa fusionQ
a ajoutéside
àP
, etQ
est MEMEARBRE àP
, mais pas àY
.
rev-list
traverse en arrière l’historique, y compris ou en excluant les commits en fonction de si --full-history
et / ou la réécriture des parents (par l’intermédiaire de --parents
ou --children
) sont utilisés. Les paramètres suivants sont disponibles.
- Mode par défaut
-
Les commits sont inclus s’ils ne sont pas MEMEARBRE à un parent (bien que ceci puisse être changé, voir
--sparse
ci-dessous). Si le commit était une fusion, et que c’était MEMEARBRE à un des parents, ne suivez que ce parent. (Même s’il y a plusieurs parents MEMEARBRE, ne suivez qu’un seul d’entre eux.) Sinon, suivez tous les parents.Il en résulte :
.-A---N---O / / / I---------D
Notez que la règle de ne suivre que le parent MEMEARBRE, s’il y en a un disponible, a entièrement supprimé
B
de la considération.C
a été pris en compte viaN
, mais il est MEMEARBRE. Les commits racines sont comparés à un arbre vide, doncI
est !MEMEARBRE.Les relations parents/enfants ne sont visibles qu’avec
--parents
, mais cela n’affecte pas les commits sélectionnés en mode par défaut, nous avons donc montré les lignes parentales. - --full-history sans réécriture des parents
-
Ce mode diffère du mode par défaut en un point : toujours suivre tous les parents d’une fusion, même si c’est MEMEARBRE à l’un d’eux. Même si plus d’un côté de la fusion a des commits qui sont inclus, cela ne signifie pas que la fusion elle-même l’est ! Dans l’exemple, nous obtenons
I A B N D O P Q
M
a été exclu parce qu’il s’agit d’un MEMEARBRE pour les deux parents.E
,C
etB
ont tous été parcourus, mais seulB
était un !MEMEARBRE, donc les autres n’apparaissent pas.Notez que sans réécriture des parents, il n’est pas vraiment possible de parler des relations parent/enfant entre les commits, donc nous les montrons déconnectés.
- --full-history avec réécriture des parents
-
Les commits ordinaires ne sont inclus que s’ils le sont !MEMEARBRE (bien que cela puisse être changé, voir
--sparse
ci-dessous).Les fusions sont toujours incluses. Cependant, leur liste de parents est réécrite : à côté de chaque parent, élaguer les commits qui ne sont pas inclus eux-mêmes. Il en résulte
.-A---M---N---O---P---Q / / / / / I B / D / \ / / / / `-------------'
À comparer avec
--full-history
sans réécrire ci-dessus. Notez queE
a été élagué parce que c’est MEMEARBRE, mais la liste parent de P a été réécrite pour contenir le parentI
deE
. Il en a été de même pourC
etN
, etX
,Y
etQ
.
En plus des paramètres ci-dessus, vous pouvez modifier si MEMEARBRE affecte l’inclusion :
- --dense
-
Les commits qui sont parcourus sont inclus s’ils ne sont pas MEMEARBRE pour aucun parent.
- --sparse
-
Tous les commits qui sont parcourus sont inclus.
Notez que sans
--full-history
, cela simplifie encore les fusions : si l’un des parents est MEMEARBRE, nous ne suivons que celui-là, donc les autres côtés de la fusion ne sont jamais parcourus. - --simplify-merges
-
Tout d’abord, construire un graphe d’historique de la même manière que
--full-history
avec la réécriture des parents (voir ci-dessus).Puis simplifier chaque commit
C
à son remplacementC'
dans l’historique final selon les règles suivantes :-
Définir
C'
surC
. -
Remplacer chaque parent
P
deC'
par sa simplificationP'
. Dans le processus, déposer les parents qui sont les ancêtres d’autres parents ou qui sont des commits racines MEMEARBRE à un arbre vide, et supprimer les doublons, mais prendre soin de ne jamais laisser tomber tous les parents auxquels nous sommes MEMEARBRE. -
Si après cette réécriture des parents,
C'
est un commit racine ou de fusion (qui a zéro ou >1 parents), un commit limite, ou !MEMEARBRE, il est conservé. Sinon, il est remplacé par son seul parent.
L’effet de ceci est mieux montré en comparant avec
--full-history
avec la réécriture des parents. L’exemple se transforme en :.-A---M---N---O / / / I B D \ / / `---------'
Notez les principales différences entre
N
,P
etQ
par rapport à--full-history
:-
'La liste des parents de
N
a été supprimée, parce qu’elle est un ancêtre de l’autre parentM
. Pourtant,N
est resté parce qu’il est !MEMEARBRE. -
De même, la liste des parents de
P
a euI
supprimé.P
a ensuite été complètement enlevé, parce qu’il avait un parent et qu’il est MEMEARBRE. -
La liste des parents de
Q
a renduY
simplifié enX
.X
a ensuite été supprimé, parce que c’était une racine MEMEARBRE.Q
a ensuite été complètement supprimée, parce qu’elle avait un parent et qu’il est MEMEARBRE.
-
Il existe un autre mode de simplification :
- --ancestry-path[=<commit>]
-
Limiter les commits affichés à ceux qui sont un ancêtre de <commit>, ou qui sont un descendant de <commit>, ou sont <commit> lui-même.
À titre d’exemple, considérons l’historique de commits suivant :
D---E-------F / \ \ B---C---G---H---I---J / \ A-------K---------------L--M
Un D..M régulier calcule l’ensemble des commits qui sont les ancêtres de
M
, mais exclut ceux qui sont les ancêtres deD
. C’est utile pour voir ce qui s’est passé dans l’historique qui a mené àM
depuis leD
, au sens de « ce queM
a qui n’existait pas dansD
». Le résultat dans cet exemple serait tous les commits, saufA
etB
(etD
lui-même, bien sûr).Quand nous voulons savoir quels commits dans
M
sont contaminés par le bogue introduit parD
et ont besoin d’être corrigés, cependant, nous pourrions vouloir voir seulement le sous-ensemble de D..M qui sont en fait des descendants deD
, c’est-à-dire en excluantC
etK
. C’est exactement ce que fait l’option--ancestry-path
. Appliqué à l’intervalle D..M, il se traduit en :E-------F \ \ G---H---I---J \ L--M
Nous pouvons également utiliser
--ancestry-path=D
au lieu de--ancestry-path
qui signifie la même chose lorsqu’il est appliqué à la plage D..M mais est juste plus explicite.Si nous sommes plutôt intéressés par un sujet donné dans cette plage, et tous les commits affectés par ce sujet, nous pouvons seulement vouloir voir ceux du sous-ensemble de
D..M
qui contiennent ce sujet dans leur chemin d’ascendance. Ainsi, en utilisant--ancestry-path=H D..M
par exemple, on obtiendrait le résultat suivant :E \ G---H---I---J \ L--M
Alors que
--ancestry-path=K D...M
donnerait comme résultatK---------------L--M
Avant de discuter d’une autre option, --show-pulls
, nous devons créer un nouvel exemple d’historique.
Un problème courant auquel les utilisateurs sont confrontés lorsqu’ils consultent l’historique simplifié est qu’un commit dont ils savent qu’il a modifié un fichier n’apparaît pas dans l’historique simplifié du fichier. Prenons un nouvel exemple et montrons comment des options telles que --full-history
et --simplify-merges
fonctionnent dans ce cas :
.-A---M-----C--N---O---P / / \ \ \/ / / I B \ R-'`-Z' / \ / \/ / \ / /\ / `---X--' `---Y--'
Pour cet exemple, supposons que I
a créé fichier.txt
qui a été modifié par A
, B
et X
de différentes manières. Les commits à parent unique C
, Z
et Y
ne modifient pas fichier.txt
. Le commit de fusion M
a été créé en résolvant le conflit de fusion pour inclure les deux modifications de A
et B
et n’est donc pas MEMEARBRE pour l’un ou l’autre. Le commit de fusion R
, cependant, a été créé en ignorant le contenu du fichier fichier.txt
à M
et en prenant seulement le contenu du fichier fichier.txt
à X
. Par conséquent, R
est MEMEARBRE à X
mais pas à M
. Enfin, la résolution de fusion naturelle pour créer N
est de prendre le contenu du fichier.txt
à R
, donc N
est MEMEARBRE à R
mais pas à C
. La fusion engage O
et P
sont MEMEARBRE à leurs premiers parents, mais pas à leurs seconds parents, Z
et Y
respectivement.
En utilisant le mode par défaut, N
et R
ont tous deux un parent MEMEARBRE, donc ces bords sont parcourus et les autres sont ignorés. Le graphique d’historique qui en résulte est :
I---X
Lors de l’utilisation de --full-history
, Git parcourt toutes les arêtes . Il découvrira les commits A
et B
et la fusion M
, mais aussi les commits de fusion O
et P
. Avec la réécriture des parents, le graphe résultant est :
.-A---M--------N---O---P / / \ \ \/ / / I B \ R-'`--' / \ / \/ / \ / /\ / `---X--' `------'
Ici, les commits de fusion O
et P
apportent un bruit supplémentaire, car ils n’ont pas réellement apporté de modification à fichier.txt
. Ils ont seulement fusionné une branche thématique qui était basée sur une ancienne version de fichier.txt
. C’est un problème courant dans les dépôts utilisant une organisation où de nombreux contributeurs travaillent en parallèle et fusionnent leurs branches thématiques le long d’un seul tronc : de nombreuses fusions sans rapport apparaissent dans les résultats de --full-history
.
Lorsque l’on utilise l’option --simplify-merges
, les valeurs O
et P
disparaissent des résultats. Cela est dû au fait que les seconds parents réécrits de O
et P
sont accessibles depuis leurs premiers parents. Ces arêtes sont supprimées et les commits ressemblent alors à des commits monoparentaux qui sont MEMEARBRE pour leur parent. C’est également le cas pour le commit N
, ce qui donne l’historique suivant :
.-A---M--. / / \ I B R \ / / \ / / `---X--'
Dans cette optique, nous voyons toutes les modifications monoparentales de A
, B
et X
. Nous voyons également la fusion M
, soigneusement résolue, et la fusion R
, pas si soigneusement résolue. Ces informations sont généralement suffisantes pour déterminer pourquoi les commits A
et B
ont « disparu » de l’historique dans la vue par défaut. Cependant, cette approche pose quelques problèmes.
La première question est celle de la performance. Contrairement à toutes les options précédentes, l’option --simplify-merges
nécessite de parcourir l’historique complet des commits avant de renvoyer un seul résultat. Cela peut rendre l’option difficile à utiliser pour les très grands dépôts.
La deuxième question est celle de l’audit. Lorsque plusieurs contributeurs travaillent sur le même dépôt, il est important de savoir quels commits de fusion ont introduit un changement dans une branche importante. La fusion problématique R
ci-dessus n’est probablement pas le commit de fusion qui a été utilisé pour fusionner dans une branche importante. Au lieu de cela, la fusion N
a été utilisée pour fusionner R
et X
dans la branche importante. Ce commit peut avoir des informations sur la raison pour laquelle la modifcation X
est venu remplacer les changements de A
et B
dans son message de commit.
- --show-pulls
-
En plus des commits indiqués dans l’historique par défaut, montrer chaque commit de fusion qui n’est pas MEMEARBRE à son premier parent, mais qui est MEMEARBRE à un parent ultérieur.
Quand un commit de fusion est inclus par
--show-pulls
, cette fusion est traitée comme si elle avait "tiré" le changement d’une autre branche. Lorsque l’on utilise--show-pulls
sur cet exemple (et aucune autre option), le graphe résultant est :I---X---R---N
Ici, les commits de fusion
R
etN
sont inclus, car ils ont tiré les commitsX
etR
dans la branche de base, respectivement. Ces fusions sont les raisons pour lesquelles les commitsA
etB
n’apparaissent pas dans l’historique par défaut.Lorsque l’option
--show-pulls
est associée à l’option--simplify-merges
, le graphe comprend toutes les informations nécessaires :.-A---M--. N / / \ / I B R \ / / \ / / `---X--'
Remarquez que puisque
M
est accessible à partir deR
, l’arête entreN
etM
a été simplifiée. Cependant,N
apparaît toujours dans l’historique comme un commit important parce qu’il a « tiré » le changementR
dans la branche principale.
L’option --simplify-by-decoration
vous donne une vue d’ensemble de la topologie de l’historique, en omettant les commits qui ne sont pas référencés par des étiquettes. Les commits sont marqués comme !MEMEARBRE(en d’autres termes, conservés après les règles de simplification de l’historique décrites ci-dessus) si (1) ils sont référencés par des étiquettes, ou (2) ils changent le contenu des chemins donnés sur la ligne de commande. Tous les autres commits sont marqués comme MEMEARBRE (soumis à une possible simplification).
TRANSFORMER LES AUTEURS
Voir gitmailmap[5].
Notez que si git shortlog
est exécuté en dehors d’un dépôt (pour traiter le contenu du journal sur une entrée standard), il cherchera un fichier .mailmap
dans le répertoire actuel.
GIT
Fait partie de la suite git[1]
TRADUCTION
Cette page de manuel a été traduite par Jean-Noël Avila <jn.avila AT free DOT fr> et les membres du projet git-manpages-l10n. Veuillez signaler toute erreur de traduction par un rapport de bogue sur le site https://github.com/jnavila/git-manpages-l10n .