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

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.

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 que HEAD, é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, ou refs/remotes lorsqu’ils sont appliqués à --branches, --tags, ou --remotes, respectivement, et ils doivent commencer par refs/ 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é par core.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 bissection refs/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 et B, 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 de B qui sont dans A ou sont équivalents en rustine à un commit en A. En d’autres termes, cela liste les commits + de git 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 avec git 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 que online et reference (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é comme ref@{Nième} (où Nième est l’index chronologique inverse dans le reflog) ou comme ref@{horodatage} (avec l’horodatage pour cette entrée), selon quelques règles :

  1. Si le point de départ est spécifié comme ref@{Nième}, afficher le format de l’index.

  2. Si le point de départ a été spécifié comme ref@{now}, afficher le format de l’horodatage.

  3. 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.

  4. 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 :

<chemins>

Les commits qui modifient les <chemins> donnés sont sélectionnés.

--simplify-by-decoration

Les commits qui sont liés à une branche ou une étiquette sont sélectionnés.

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 fichier quux existe avec le contenu 'quux'. Les commits initiaux sont comparés à un arbre vide, donc I est !MEMEARBRE.

  • Dans A, foo ne contient que “foo”.

  • B contient le même changement que A. Sa fusion M est triviale et donc MEMEARBRE pour tous les parents.

  • C ne change pas foo, mais sa fusion N le change en “foobar”, donc ce n’est pas MEMEARBRE à aucun parent.

  • D met foo sur baz. Sa fusion O combine les chaînes de caractères de N et D à “foobarbaz” ; c’est-à-dire qu’elle n’est pas MEMEARBRE à aucun parent.

  • E change quux en “xyzzy”, et sa fusion P 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 fichier side, et Y l’a modifié. Y est MEMEARBRE à X. Sa fusion Q a ajouté side à P, et Q 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 via N, mais il est MEMEARBRE. Les commits racines sont comparés à un arbre vide, donc I 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 et B ont tous été parcourus, mais seul B é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 que E a été élagué parce que c’est MEMEARBRE, mais la liste parent de P a été réécrite pour contenir le parent I de E. Il en a été de même pour C et N, et X, Y et Q.

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 remplacement C' dans l’historique final selon les règles suivantes :

  • Définir C' sur C.

  • Remplacer chaque parent P de C' par sa simplification P'. 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 et Q par rapport à --full-history :

  • 'La liste des parents de N a été supprimée, parce qu’elle est un ancêtre de l’autre parent M. Pourtant, N est resté parce qu’il est !MEMEARBRE.

  • De même, la liste des parents de P a eu I 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 rendu Y simplifié en X. 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 de D. C’est utile pour voir ce qui s’est passé dans l’historique qui a mené à M depuis le D, au sens de « ce que M a qui n’existait pas dans D ». Le résultat dans cet exemple serait tous les commits, sauf A et B (et D lui-même, bien sûr).

Quand nous voulons savoir quels commits dans M sont contaminés par le bogue introduit par D 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 de D, c’est-à-dire en excluant C et K. 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 et N sont inclus, car ils ont tiré les commits X et R dans la branche de base, respectivement. Ces fusions sont les raisons pour lesquelles les commits A et B 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 de R, l’arête entre N et M a été simplifiée. Cependant, N apparaît toujours dans l’historique comme un commit important parce qu’il a « tiré » le changement R 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 .