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.34.1 no changes
- 2.34.0 11/15/21
- 2.33.1 10/12/21
- 2.33.0 08/16/21
- 2.32.0 06/06/21
- 2.31.1 no changes
- 2.31.0 03/15/21
- 2.30.1 → 2.30.2 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
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
-
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
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.
- --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 le 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 le message de log 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
-
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. Ne peut pas être combiné avec --bisect.
- --not
-
Inverser la signification du préfixe'^' (ou son absence) pour tous les spécificateurs de révision suivants, jusqu’au prochain
--not
. - --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
,--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. - --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. Ne peut être combiné avec --first-parent. - --stdin
-
En plus des <commit> indiqués sur la ligne de commande, les lire à partir de l’entrée standard. Si un séparateur
--
est vu, arrêter la lecture des commits et commencer à lire les chemins pour limiter le résultat. - --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 le 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
-
Après une fusion ratée, afficher les références qui touchent les fichiers en conflit et qui n’existent pas sur toutes les têtes à fusionner.
- --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
-
Lorsqu’on lui donne une plage de commits à afficher (par exemple’commit1..commit2' ou’commit2 ^commit1'), seuls les commits qui existent directement sur la chaîne des ancêtres entre commit1 et commit2, c’est-à-dire les commits qui sont à la fois descendants de commit1 et ancêtres de commit2, sont affichés.
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 sans 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
-
Limiter les commits affichés à ceux qui se trouvent directement sur la chaîne des ancêtres entre les commits "from" et "to" dans la plage de commit donnée. C’est-à-dire n’afficher que les commits qui sont l’ancêtre du commit "to" et les descendants du commit "from".
À 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
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-history
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
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]
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 .