Git

git-log last updated in 2.34.1

NOM

git-log - Afficher les journaux de validation

SYNOPSIS

git log [<options>] [<plage de révision>] [[--] <chemin>…]

DESCRIPTION

Affiche les journaux de validation.

La commande prend les options applicables à la commande git rev-list pour contrôler ce qui est montré et comment, et les options applicables aux commandes git diff' pour contrôler la façon dont les modifications que chaque validation introduit sont affichées.

OPTIONS

--follow

Continuer à lister l’historique d’un fichier au-delà des renommages (ne fonctionne que pour un seul fichier).

--no-decorate

--decorate[=short|full|auto|no]

Imprimer les noms de réference des commits affichés. Si short est spécifié, les préfixes des noms de référence refs/heads/, refs/tags/ et refs/remotes/ ne seront pas affichés. Si full est spécifié, le nom complet de la référence (y compris le préfixe) sera imprimé. Si auto est spécifié, alors si la sortie va à un terminal, les noms de référence sont affichés comme si short ont été donné, sinon aucun nom de référence n’est affiché. L’option par défaut est short.

--decorate-refs=<motif>

--decorate-refs-exclude=<motif>

Si aucun --decorate-refs' n'est donné, faire comme si tous les refs étaient inclus. Pour chaque candidat, ne pas l'utiliser pour la décoration s'il correspond à un motif fourni à `--decorate-refs-exclude' ou s'il ne correspond à aucun des motifs fournis à `--decorate-refs'. L'option de configuration `log.excludeDecoration permet d’exclure les références des décorations, mais un motif explicite --decorate-refs remplacera une correspondance dans log.excludeDecoration.

--source

Imprimer le nom de la référence donné sur la ligne de commande par lequel chaque commit a été atteint.

--[no-]mailmap

--[no-]use-mailmap

Utiliser le fichier mailmap pour mapper les noms d’auteurs et de validateurs et les adresses email avec les vrais noms et adresses email canoniques. Voir git-shortlog[1].

--full-diff

Sans ce drapeau, git log -p <p <chemin>... affiche les commits qui touchent les chemins spécifiés, et diffs sur les mêmes chemins spécifiés. Avec ceci, le diff complet est affiché pour les commits qui touchent les chemins spécifiés ; cela signifie que "<chemin>…" limite seulement les commits, et ne limite pas le diff pour ces commits.

Notez que cela affecte tous les types de sortie basés sur le diff, par exemple ceux produits par ---stat, etc.

--log-size

Inclure une ligne 'log size <nombre>' dans la sortie pour chaque commit, où <nombre> est la longueur du message de ce commit en octets. Destiné à accélérer les outils qui lisent les messages de journal de la sortie git log en leur permettant d’allouer de l’espace à l’avance.

-L <début>,<fin>:<fichier>

-L :<nom-de-fonction>:<fichier>

Tracer l’évolution de la plage de lignes donnée par "<début>,<fin>" (ou la regex de nom de la fonction <nom-de-fonction>) dans le fichier <fichier>. Vous ne pouvez pas donner de limiteurs de spécificateur de chemin. Ceci est actuellement limité à une marche à partir d’une seule révision, c’est-à-dire que vous ne pouvez donner qu’aucun ou un seul argument de révision, <début> et <fin> (ou <nom-de-fonction>) doivent exister dans la révision de départ. Vous pouvez spécifier cette option plusieurs fois. Cette option implique --patch. L’affichage de la rustine peut être supprimé en utilisant --no-patch, mai les autres formats de diff (--raw, --numstat, --shortstat, --dirstat, --summary, --name-only, --name-status, --check) ne sont pas implantés actuellement.

<début> et <fin> peuvent prendre l’une de ces formes :

nombre

Si <début> ou <fin> est un nombre, il spécifie un numéro de ligne absolu (les lignes comptent à partir de 1).
/regex/

Cette forme utilisera la première ligne correspondant à la regex POSIX donnée. Si <début> est une regex, la recherche se fera à partir de la fin de la plage -L précédente, le cas échéant, sinon à partir du début du fichier. Si <début> est "^/regex/", la recherche se fera à partir du début du fichier. Si <fin> est une regex, la recherche débutera à partir de la ligne donnée par <début>.
+ offset ou -offset

Ceci n’est valable que pour <fin> et spécifiera un nombre de lignes avant ou après la ligne donnée par <début>.

Si ":<nom-de-fonction>" est donné à la place de <début> et de <fin>, il s’agit d’une expression régulière qui indique la plage depuis première ligne qui correspond à <nom-de-fonction>, jusqu’à la ligne de nom-de-fonction suivante. La recherche de ":<nom-de-fonction>" se fait à partir de la fin de la plage -L précédente, s’il y en a une, sinon à partir du début du fichier. La recherche de "^:<nom-de-fonction>" commence au début du fichier.

<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 depuis le commit courant (c-à-d HEAD), mais pas depuis origin. Pour une liste complète des façons d’épeler <plage-de-révision>, voir la section’Spécification des plages' de gitrevisions[7].
[--] <chemin>…: Afficher uniquement les commits qui sont suffisants pour expliquer comment les fichiers qui correspondent aux chemins spécifiés sont venus à exister. Voir Simplification de l’historique ci-dessous pour plus de détails et d’autres modes de simplification.

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 :

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 :

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

Ordre des commits

Par défaut, les commits sont affichés dans l’ordre chronologique inverse.

--date-order

N’afficher aucun parent avant que tous ses enfants ne soient affichés, mais sinon montrer les commits dans l’ordre de l’horodatage des commits.

--author-date-order

N’afficher aucun parent avant que tous ses enfants ne soient affichés, mais autrement afficher les commits dans l’ordre d’horodatage de l’auteur.

--topo-order

N’afficher aucun parent avant que tous ses enfants ne soient affichés, et éviter d’afficher des commits entremêlés sur plusieurs lignes d’historique.

Par exemple, dans un historique de commit comme celui-ci :

    ---1----2----4----7
	\	       \
	 3----5----6----8---

où les nombres indiquent l’ordre des horodatages de commit, git rev-list et consorts avec --date-order affichent les commits dans l’ordre d’horodatage : 8 7 6 5 4 3 2 1.

Avec ‘--topo-order’, ils afficheraient 8 6 5 5 3 3 7 4 7 4 2 1 (ou 8 7 4 2 2 6 5 5 3 1) ; certains commits plus anciens sont affichés avant les plus récents afin d’éviter de montrer mélangés ensemble les commits de deux pistes de développement parallèles.

--reverse

Sortir les commits choisis pour être affichés (voir la section Limitation des commits ci-dessus) dans l’ordre inverse. Ne peut pas être combiné avec --walk-reflogs.

Traversée d’objets

Ces options sont principalement destinées à l’empaquetage des dépôts Git.

--no-walk[=(sorted|unsorted)]: Montrer seulement les commits donnés, mais ne pas traverser leurs ancêtres. Ceci n’a aucun effet si une plage est spécifiée. Si l’argument unsorted est donné, les commits sont affichés dans l’ordre dans lequel ils ont été donnés sur la ligne de commande. Sinon (si sorted ou aucun argument n’a été donné), les commits sont affichés dans l’ordre chronologique inverse par date de validation. Ne peut pas être combiné avec --graph.
--do-walk: Remplacer un --no-walk précédent.

Formatage des commits

--pretty[=<format>]
--format=<format>: Formater le contenu des journaux de commits dans un format donné, où <format> peut être au choix parmi oneline, short, medium, full, fuller, reference, email, raw, format:<chaîne> et tformat:<chaîne>. Lorsque <format> n’est rien de ce qui précède, et qu’il contient'%format', il agit comme si --pretty=tformat:<format> était donné.

Voir la section "MISE EN FORME" pour plus de détails pour chaque format. Lorsque la partie'=<format>' est omise, la valeur par défaut est’medium'.

Note : vous pouvez spécifier le format par défaut dans la configuration du dépôt commit.cleanup (voir git-config[1]).
--abbrev-commit: Au lieu d’afficher le nom complet hexadécimal de 40 octets de l’objet commit, afficher seulement un préfixe partiel. Le nombre de chiffres peut être spécifié avec "--abbrev=<n>". (qui modifie également la sortie diff, si elle est affichée).

Cela devrait rendre "--pretty=online" beaucoup plus lisible pour les personnes utilisant des terminaux à 80 colonnes.
--no-abbrev-commit: Afficher le nom complet hexadécimal de 40 octets de l’objet commit. Ceci annule --abbrev-commit et les options qui l’impliquent telles que "--online". Elle remplace également la variable log.abbrevCommit.
--oneline: C’est un raccourci pour "--pretty=online --abbrev-commit" utilisés ensemble.
--encoding=<codage>: Les objets commit enregistrent l’encodage utilisé pour le message de log dans leur en-tête d’encodage ; cette option peut être utilisée pour indiquer à la commande de recoder le message de log du commit dans l’encodage préféré par l’utilisateur. Pour les commandes hors plomberie, cette valeur par défaut est UTF-8. Notez que si un objet prétend être encodé en X et que nous sortons en X, nous allons sortir l’objet à l’identique ; cela signifie que les séquences invalides dans la livraison originale peuvent être copiées dans la sortie.
--expand-tabs=<n>
--expand-tabs
--no-expand-tabs: Effectuer une extension de tabulation (remplacer chaque tabulation par suffisamment d’espaces pour remplir jusqu’à la colonne d’affichage suivante qui est multiple de'<n>') dans le message de journal avant de l’afficher dans la sortie. --expand-tabs est un raccourci pour --expand-tabs=8, et --no-expand-tabs est un raccourci pour --expand-tabs=0, qui désactive l’extension des tabulations.

Par défaut, les tabulations sont développées par les formatages qui indentent le message de log par 4 espaces (c’est-à-dire medium, qui est le format par défaut, full, fuller).
--notes[=<ref>]: Afficher les notes (voir git-notes[1]) qui annotent le commit, lors de l’affichage du message du journal de commit. C’est la valeur par défaut pour les commandes git log, git show et git whatchanged lorsqu’il n’y a pas d’option --pretty, --format ou --online sur la ligne de commande.

Par défaut, les notes affichées proviennent des références de notes listées dans les variables core.notesRef et notes.displayRef (ou les substitutions d’environnement correspondantes). Voir git-config[1] pour plus de détails.

Avec un argument optionnel'<ref>', utiliser la référence pour trouver les notes à afficher. La référence peut spécifier le nom complet de référence quand elle commence par refs/notes/ ; quand elle commence par notes/, refs/ et sinon refs/notes/ est préfixé pour former un nom complet de la référence.

Plusieurs options --notes peuvent être combinées pour contrôler quelles notes sont affichées. Exemples : "--notes=foo" affichera uniquement les notes de "refs/notes/foo" ; "--notes=foo --notes" affichera les notes de "refs/notes/foo" et des ref(s) de notes par défaut.
--no-notes: Ne pas afficher les notes. Ceci annule l’option --notes ci-dessus, en réinitialisant la liste des références de notes à partir desquelles les notes sont affichées. Les options sont analysées dans l’ordre donné sur la ligne de commande, par exemple "--notes --notes --notes=foo --no-notes --notes=bar" n’affichera que les notes "refs/notes/bar".
--show-notes[=<reférence>]
--[no-]standard-notes: Ces options sont obsolètes. Utilisez plutôt les options --notes/--no-notes ci-dessus.
--show-signature: Vérifier la validité d’un objet commit signé en passant la signature à ‘gpg --verify’ et afficher le résultat.

--relative-date

Synonyme de --date=relative.

--date=<format>

Ne prendre effet que pour les dates indiquées dans un format lisible par l’homme, par exemple lors de l’utilisation de --pretty. La variable config log.date définit une valeur par défaut pour l’option --date de la commande log. Par défaut, les dates sont affichées dans le fuseau horaire d’origine (soit celui du validateur ou celui de l’auteur). Si -local est ajouté au format (p. ex., iso-local), le fuseau horaire local de l’utilisateur est utilisé à la place.

--date=relative affiche les dates relatives à l’heure actuelle, par exemple “Il y a 2 heures”. L’option -local n’a aucun effet pour --date=relative.

--date=local est un alias pour --date=default-local.

--date=iso (ou --date=iso8601) montre les horodatages dans un format similaire à ISO 8601. Les différences par rapport au format strict ISO 8601 sont :

une espace au lieu du délimiteur date/heure T
une espace entre l’heure et le fuseau horaire
pas de deux points entre les heures et les minutes du fuseau horaire

--date=iso-strict (ou --date=iso8601-strict) affiche les horodatages au format ISO 8601 strict.

--date=rfc (ou --date=rfc2822) montre les horodatages au format RFC 2822, souvent trouvés dans les messages électroniques.

--date=short montre seulement la date, mais pas l’heure, au format AAA-MM-JJ.

--date=raw montre la date en secondes depuis l’époque (1970-01-01 00:00:00 UTC), suivi d’une espace, puis le fuseau horaire en décalage par rapport à UTC (un + ou - avec quatre chiffres ; les deux premiers sont des heures, et les deux seconds des minutes), c’est-à-dire comme si l’horodatage était formaté avec strftime("%s %z")). Notez que l’option -local n’affecte pas la valeur des secondes depuis l’écho (qui est toujours mesurée en UTC), mais commute la valeur du fuseau horaire qui l’accompagne.

--date=human montre le fuseau horaire si le fuseau horaire ne correspond pas au fuseau horaire actuel, et n’affiche pas la date complète s’il y a correspondance (c’est-à-dire ne pas afficher l’année pour les dates qui sont "cette année", mais aussi sauter la date complète elle-même si elle est dans les derniers jours et que nous pouvons juste indiquer le jour de la semaine passée). Pour les dates plus anciennes, l’heure et la minute sont également omises.

--date=unix affiche la date sous forme d’un horodatage d’époque Unix (secondes depuis 1970). Comme dans le cas de " --raw ", c’est toujours en UTC et donc " --local " n’a aucun effet.

--date=format :... alimente le format ... vers strftime de votre système , sauf pour %z et %Z, qui sont gérés en interne. Utilisez --date=format:%c pour afficher la date dans le format préféré de la locale de votre système. Voir le manuel de strftime pour une liste complète des espaces réservés de format. Quand on utilise -local, la syntaxe correcte est --date=format-local :....

--date=default est le format par défaut, et est similaire à --date=rfc2822, avec quelques exceptions :

il n’y a pas de virgule après le jour de la semaine
le fuseau horaire est omis lorsque le fuseau horaire local est utilisé

--parents

Afficher aussi les parents du commit (sous la forme "parent du commit…"). Permet également la réécriture des parents, voir " Simplification de l’historique " ci-dessus.

--children

Afficher aussi les enfants du commit (sous la forme "commit child…"). Permet également la réécriture des parents, voir " Simplification de l’historique " ci-dessus.

--left-right

Indiquer de quel côté d’une différence symétrique un commit est accessible. Les commits de gauche sont préfixés par " < " et ceux de droite par " > ". Si on combine avec --boundary, ces commits sont préfixés par -.

Par exemple, si vous avez cette topologie :

	     y---b---b  branche B
	    / \ /
	   /   .
	  /   / \
	 o---x---a---a  branche A

vous obtiendriez une sortie comme celle-ci :

	$ git rev-list --left-right --boundary --pretty=oneline A...B

	>bbbbbbb... 3rd on b
	>bbbbbbb... 2nd on b
	<aaaaaaa... 3rd on a
	<aaaaaaa... 2nd on a
	-yyyyyyy... 1st on b
	-xxxxxxx... 1st on a

--graph

Dessiner une représentation graphique en texte de l’historique du commit sur la gauche de la sortie. Cela peut entraîner l’impression de lignes supplémentaires entre les validations, afin que l’historique du graphique soit correctement tracé. Ne peut pas être combiné avec --no-walk.

Cela permet la réécriture des parents, voir « Simplification de l’historique » ci-dessus.

Cela implique l’option --topo-order par défaut, mais l’option --date-order peut aussi être spécifiée.

--show-linear-break [=<barrière>]

Lorsque --graph n’est pas utilisé, toutes les branches de l’historique sont aplaties, ce qui peut rendre difficile de voir que les deux commits consécutifs n’appartiennent pas à une branche linéaire. Dans ce cas, cette option met une barrière entre les deux. Si <barrière> est spécifié, c’est la chaîne de caractères qui sera affichée à la place de celle par défaut.

Formatage des diffs

Voici la liste des options qui permettent de contrôler la mise en forme de la sortie de la commande diff. Certaines d’entre elles sont spécifiques à git-rev-list[1], mais d’autres options de diff peuvent être spécifiées. Voir git-diff-files[1] pour plus d’options.

-c: Avec cette option, la sortie de diff pour un commit de fusion montre les différences de chacun des parents vers le résultat de la fusion simultanément au lieu de montrer une à une les différences par paires entre un parent et le résultat. De plus, il ne répertorie que les fichiers qui ont été modifiés par tous les parents.
--cc: Ce drapeau implique l’option -c et compresse davantage la sortie du patch en omettant les morceaux inintéressants dont le contenu dans les parents n’a que deux variantes et le résultat de la fusion choisit l’une d’entre elles sans modification.
--combined-all-paths: Cet indicateur fait en sorte que les diffs combinés (utilisés pour les commits de fusion) listent le nom du fichier de tous les parents. Il n’a donc d’effet que lorsque -c ou --cc sont spécifiés, et n’est probablement utile que si des changements de nom de fichier sont détectés (c.-à-d. lorsque la détection de renommage ou de copie a été demandée).
-m: Ce drapeau fait que les commits de fusion montrent la différence complète comme les commits réguliers ; pour chaque parent de la fusion, une entrée de journal et une différence séparées sont générées. Une exception est que seule la différence par rapport au premier parent est affichée quand l’option --first-parent est donnée ; dans ce cas, la sortie représente les modifications que la fusion a apportées dans la branche alors courante.
-r: Afficher les différences récursives.
-t: Afficher les objets arbres dans la sortie diff. Cela implique -r.

FORMATS AUTOMATIQUES

Si le commit est une fusion, et si la mise en forme n’est pas oneline, email ou raw, une ligne supplémentaire est insérée avant la ligne Author:. Cette ligne commence par "Merge:" et les empreintes des commits ancêtres sont affichées, séparées par des espaces. Notez que les commits énumérés ne sont pas nécessairement la liste des commits parents directs si vous avez limité votre vue de l’historique : par exemple, si vous n’êtes intéressé que par les modifications liées à un certain répertoire ou fichier.

Il existe plusieurs formats intégrés, et vous pouvez définir des formats supplémentaires en définissant une option pretty.<nom> config à soit un nouveau nom de format, soit une chaîne’format:', comme décrit ci-dessous (voir git-config[1]). Voici le détail des formats intégrés :

oneline
```
<empreinte> <ligne de titre>
```
C’est conçu pour être aussi compact que possible.

short

commit <empreinte>
Author: <auteur>

<ligne de titre>

medium

commit <empreinte>
Author: <auteur>
Date:   <date d'auteur>

<ligne de titre>

<message de validation complet>

full

commit <empreinte>
Author: <auteur>
Commit: <validateur>

<ligne de titre>

<message de validation complet>

fuller

commit <empreinte>
Author:     <auteur>
AuthorDate: <date d'auteur>
Commit:     <validateur>
CommitDate: <date de validation>

<ligne de titre>

<message de validation complet>

reference
```
<empreinte abrégée> (<ligne de titre>, <courte date d'auteur>)
```
Ce format est utilisé pour faire référence à un autre commit dans un message de validation et est le même que --pretty='format:%C(auto)%h (%s, %ad)'. Par défaut, la date est formatée avec --date=short à moins qu’une autre option --date ne soit explicitement spécifiée. Comme pour tout format: avec des espaces réservés de format, sa sortie n’est pas affectée par d’autres options comme --decorate et --walk-reflogs.

email

From <empreinte> <date>
From: <auteur>
Date: <date d'auteur>
Subject: [PATCH] <ligne de titre>

<message de validation complet>

mboxrd

Comme email, mais les lignes dans le message de validation commençant par "From" (précédé de zéro ou plus ">") sont citées avec ">" pour ne pas être confondues avec le début d’un nouveau commit.
raw

Le format’raw' montre le commit entier telle qu’elle est stockée dans l’objet commit. Notamment, les empreintes sont affichées dans leur intégralité, que --abbrev ou --no-abbrev soient utilisés ou non, et l’information parents indiquent le véritable commit parent, sans tenir compte des greffes ou de la simplification d’historique. Notez que ce format affecte la façon dont les commits sont affichés, mais pas la façon dont la différence est affichée, par exemple avec git log --raw. Pour obtenir les noms complets des objets dans un format de diff brut, utilisez --no-abbrev.
format:<chaîne>

Le format’format:<chaîne>' vous permet de spécifier quelles informations vous voulez afficher. Cela fonctionne un peu comme le format printf, à l’exception notable que vous obtenez une nouvelle ligne avec'%n' au lieu de'\n'.

Par exemple,format : "L’auteur de %h était %an, %ar%nL’entête était >>%s<<<%n" afficherait quelque chose comme ceci :
```
L'auteur de fe6e0ee était Junio C Hamano, 23 hours ago
L'entête était >>t4119: test autocomputing -p<n> for traditional diff input.<<
```
Les espaces réservés sont :
- Les places qui s’étendent à un seul caractère littéral :
  
  %n
  
  retour à la ligne
  
  %%
  
  un % brut
  
  %x00
  
  afficher un octet à partir d’un code hexagonal
- Espaces réservés qui affectent le formatage des espaces réservés ultérieurs :
  
  %Cred
  
  passe la couleur au rouge
  
  %Cgreen
  
  passe la couleur au vert
  
  %Cblue
  
  passe la couleur au bleu
  
  %Creset
  
  réinitialise la couleur
  
  %C(…)
  
  la spécification de la couleur, comme décrit sous Valeurs dans la section section "FICHIER DE CONFIGURATION" de git-config[1]. Par défaut, les couleurs ne sont affichées que lorsqu’elles sont activées pour la sortie des journaux (par color.diff, color.ui, ou --color, et en respectant les paramètres auto du premier si nous allons sur un terminal). %C(auto,...) est accepté comme synonyme historique de la valeur par défaut (par exemple, %C(auto,red)). Spécifier %C(always,...) affichera les couleurs même si la couleur n’est pas activée autrement (bien qu’il faille toujours utiliser --color=always pour activer la couleur pour toute la sortie, y compris ce format et tout ce que git peut colorier). auto seul (c’est-à-dire %C(auto)) activera la coloration automatique sur les places suivantes jusqu’à ce que la couleur soit à nouveau changée.
  
  %m
  
  marque à gauche (<), à droite (>) ou de limite (-)
  
  %w([<w>[,<i1>[,<i2>]]])
  
  basculer les retours à la ligne, à l’instar de l’option-w de git-shortlog[1].
  
  %<(<N>[,tronq|tronqg|tronqm])
  
  faire le prochain espace réservé prendre au moins N colonnes, en remplissant les espaces à droite si nécessaire. Au choix, tronquer au début (tronqg), au milieu (tronqm) ou à la fin (tronq) si la sortie est plus longue que N colonnes. Notez que la troncation ne fonctionne correctement qu’avec N >= 2.
  
  %<|(<N>)
  
  faire le prochain espace réservé prendre au moins jusqu’au Nième colonnes, en insérant des espaces à droite si nécessaire
  
  %>(<N>), %>|(<N>)
  
  similaire à %<(<N>), %<|(<N>) respectivement, mais en insérant des espaces à gauche
  
  %>>(<N>), %>>|(<N>)
  
  similaire à %>(<N>), %>|(<N>) respectivement, sauf que si le prochain espace réservé prend plus d’espaces que prévu et qu’il y a des espaces à sa gauche, utiliser ces espaces
  
  %><(<N>), %><|(<N>)
  
  similaire à %<(<N>), %<|(<N>) respectivement, mais en calant des deux côtés (c’est-à-dire que le texte est centré)
- Espaces réservés développant les informations extraites du commit :
  %H
  
  empreinte du commit
  
  %h
  
  empreinte abrégée du commit
  
  %T
  
  empreinte de l’arbre
  
  %t
  
  empreinte abrégée de l’arbre
  
  %P
  
  empreintes des parents
  
  %p
  
  empreintes abrégés des parents
  
  %an
  
  nom de l’auteur
  
  %aN
  
  nom de l’auteur (en respectant .mailmap, voir git-shortlog[1] ou git-blame[1])
  
  %ae
  
  e-mail de l’auteur
  
  %aE
  
  e-mail de l’auteur (en respectant .mailmap, voir git-shortlog[1] ou git-blame[1])
  
  %al
  
  partie locale de l’e-mail de l’auteur (la partie avant le signe "@")
  
  %aL
  
  partie locale de l’auteur (voir %al) en respectant le fichier .mailmap, voir git-shortlog[1] ou git-blame[1])
  
  %ad
  
  date de l’auteur (le format respecte l’option --date=)
  
  %aD
  
  date d’auteur, style RFC2822
  
  %ar
  
  date de l’auteur, date relative
  
  %at
  
  date de l’auteur, horodatage UNIX
  
  %ai
  
  date de création, format de type ISO 8601
  
  %aI
  
  date d’auteur, format strict ISO 8601
  
  %as
  
  date d’auteur, format court (AAAA-MM-JJ)
  
  %cn
  
  nom du validateur
  
  %cN
  
  nom du validateur (en respectant .mailmap, voir git-shortlog[1] ou git-blame[1])
  
  %ce
  
  e-mail du validateur
  
  %cE
  
  e-mail du validateur (en respectant .mailmap, voir git-shortlog[1] ou git-blame[1])
  
  %cl
  
  partie locale de l’e-mail du validateur (la partie avant le signe "@")
  
  %cL
  
  partie locale du validateur (voir %cl) en respectant .mailmap, voir git-shortlog[1] ou git-blame[1])
  
  %cd
  
  date de validation (le format respecte l’option --date=)
  
  %cD
  
  date de validation, style RFC2822
  
  %cr
  
  date de validation, date relative
  
  %ct
  
  date de validation, horodatage UNIX
  
  %ci
  
  date de validation, format de type ISO 8601
  
  %cI
  
  date de validation, format ISO 8601 strict
  
  %cs
  
  date de validation, format court (AAAA-MM-JJ)
  
  %d
  
  les noms de ref, comme l’option --decorate de git-log[1].
  
  %D
  
  les noms des refs, sans encadrement par « ( » et « ) ».
  
  %S
  
  nom de ref fourni en ligne de commande par lequel le commit a été atteint (comme git log --source), ne fonctionne qu’avec git log
  
  %e
  
  encodage
  
  %s
  
  titre
  
  %f
  
  ligne de titre aseptisée, convenant pour un nom de fichier
  
  %b
  
  corps
  
  %B
  
  corps brut (sujet et corps non enveloppés)
  
  %N
  
  notes du commit
  
  %GG
  
  message de vérification brut de GPG pour un commit signé
  
  %G?
  
  afficher "G" pour une bonne signature (valide), "B" pour une mauvaise signature, "U" pour une bonne signature avec une validité inconnue, "X" pour une bonne signature qui a expiré, "Y" pour une bonne signature faite par une clé expirée, "R" pour une bonne signature faite par une clé révoquée, "E" si la signature ne peut pas être vérifiée (par exemple la clé est manquante) et "N" pour aucune signature
  
  %GS
  
  affiche le nom du signataire d’un commit signé
  
  %GK
  
  afficher la clé utilisée pour signer un commit signé
  
  %GF
  
  afficher l’empreinte digitale de la clé utilisée pour signer un commit signé
  
  %GP
  
  afficher l’empreinte digitale de la clé primaire dont la sous-clé a été utilisée pour signer un commit signé
  
  %GT
  
  afficher le niveau de rouille de la clé utilisée pour signer un commit signé
  
  %gD
  
  sélecteur de reflog, par exemple, refs/stash@{1}` ou refs/stash@{2 minutes ago} ; le format suit les règles décrites pour l’option -g'. La partie avant `@' est le refname tel qu'il est donné sur la ligne de commande (donc `git log -g refs/heads/master produirait refs/heads/master@{0}).
  
  %gd
  
  sélecteur de reflog raccourci ; identique à %gD', mais la partie du nom du reflog est raccourcie pour la lisibilité humaine (ainsi `refs/heads/master devient simplement master).
  
  %gn
  
  nom de l’identité reflog
  
  %gN
  
  nom de l’identité du reflog (en respectant le fichier.mailmap, voir git-shortlog[1] ou git-blame[1])
  
  %ge
  
  adresse de courriel d’identité reflog
  
  %gE
  
  adresse de courriel de l’identité reflog (en respectant le fichier .mailmap, voir git-shortlog[1] ou git-blame[1])
  
  %gs
  
  titre du reflog
  
  %(trailers[:options])
  
  afficher les lignes d’attribut du corps comme interprétés par git-interpret-trailers[1]. La chaîne trailers peut être suivie de deux-points et de zéro ou plus d’options séparées par des virgules :
  
  key=<K>' : affiche uniquement les chaînes d’attributs avec la clé spécifiée. L’appariement se fait de façon insensible à la casse et la virgule finale est facultative. Si l’option est donnée plusieurs fois, les lignes d’attributs correspondant à l’une des clés sont affichées. Cette option active automatiquement l’option only de sorte que les lignes non-attribut dans le bloc d’attributs soient masquées. Si ce n’est pas désiré, ce peut être désactivé avec only=false. Par exemple, %(trailers:key=Reviewed-by) affiche les lignes d’attribut avec la clé Reviewed-by.
  
  only[=val] : permet de sélectionner si les lignes non-attribut du bloc d’attributs doivent être incluses. Le mot-clé only peut être éventuellement suivi d’un signe égal et d’une valeur true, on, yes pour omettre ou false, off, no pour afficher les lignes non-attribut. Si l’option est donnée sans valeur, elle est activée. Si elle est donnée plusieurs fois, la dernière valeur est utilisée.
  
  separator=<SEP> : spécifie un séparateur inséré entre les lignes d’attributs. Lorsque cette option n’est pas activée, chaque ligne d’attribut est terminée par un caractère de saut de ligne. La chaîne SEP peut contenir les codes de formatage littéral décrits ci-dessus. Pour utiliser la virgule comme séparateur, il faut utiliser %x2C car sinon elle serait analysée comme option suivante. Si l’option séparateur est donnée plusieurs fois, seule la dernière est utilisée. Par exemple, %(trailers:key=Ticket,separator=%x2C ) affiche toutes les lignes d’attributs dont la clé est « Ticket » séparées par une virgule et un espace.
  
  unfold[=val] : se comporter comme si l’option --unfold d’interprétation des attributs était donnée. De la même manière que pour only, il peut être suivi d’un signe égal et d’une valeur explicite. Par exemple, %(trailers:only,unfold=true) déplie et affiche toutes les lignes d’attributs.
  
  valueonly[=val] : sauter la partie clé de la ligne d’attribut et n’afficher que la partie valeur. Ceci permet aussi optionnellement une valeur explicite.

Note

Certains espaces réservés peuvent dépendre d’autres options données au moteur de traversée de révisions. Par exemple, les options de reflog %g* inséreront une chaîne vide à moins que nous ne traversions des entrées de reflog (par exemple, par git log -g). Les caractères de remplissage %d et %D utiliseront le format de décoration « short » si --decorate n’a pas déjà été fourni sur la ligne de commande.

Si vous ajoutez un + (signe plus) après'%' d’un espace réservé, un saut de ligne est inséré immédiatement avant l’expansion si et seulement si l’espace réservé se développe en une chaîne non vide.

Si vous ajoutez un - (signe moins) après'%' d’un caractère de remplissage, tous les sauts de ligne consécutifs précédant immédiatement l’expansion sont supprimés si et seulement si l’espace réservé se développe en une chaîne vide.

Si vous ajoutez un ‘`(espace) après’%' d’un espace réservé, un espace est inséré immédiatement avant l’expansion si et seulement si l’espace réservé se développe en une chaîne non vide.

tformat:

Le format’tformat:' fonctionne exactement comme’format:', sauf qu’il fournit une sémantique « terminator » au lieu de « separator ». En d’autres termes, chaque commit a le caractère de fin de message (habituellement une nouvelle ligne) ajouté, plutôt qu’un séparateur placé entre les entrées. Cela signifie que l’entrée finale d’un format à une ligne se terminera correctement par une nouvelle ligne, tout comme le format "oneline". Par exemple :
```
$ git log -2 --pretty=format:%h 4da45bef \
  | perl -pe '$_ .= " -- NO NEWLINE\n" unless /\n/'
4da45be
7134973 -- NO NEWLINE

$ git log -2 --pretty=tformat:%h 4da45bef \
  | perl -pe '$_ .= " -- NO NEWLINE\n" unless /\n/'
4da45be
7134973
```
De plus, toute chaîne non reconnue qui contient un % est interprétée comme si elle avait tformat: devant elle. Par exemple, ces deux éléments sont équivalents :
```
$ git log -2 --pretty=tformat:%h 4da45bef
$ git log -2 --pretty=%h 4da45bef
```

OPTIONS COMMUNES DE DIFF

-p

-u

--patch

Générer un correctif (voir section sur la génération de correctifs).

-s

--no-patch

Supprimer la sortie diff. Utile pour les commandes telles que git show qui affichent la rustine par défaut, ou pour supprimer l’effet de --patch.

-U<n>

--unified=<n>

Générer des diffs avec <n> lignes de contexte au lieu des trois habituelles. Implique --patch. Implique -p.

--output=<fichier>

Sortie vers un fichier spécifique au lieu de stdout.

--output-indicator-new=<caractère>

--output-indicator-old=<caractère>

--output-indicator-context=<caractère>

Spécifier le caractère utilisé pour indiquer les lignes nouvelles, anciennes ou contextuelles dans la rustine générée. Normalement, il s’agit de +, - et ' ' respectivement.

--raw

Pour chaque commit, afficher un résumé des modifications en format de diff brut. Voir la section « FORMAT DE SORTIE BRUT » de git-diff[1]. C’est différent de l’affichage du journal en format brut, que vous pouvez obtenir avec --format=raw.

--patch-with-raw

Synonyme de -p --raw.

--indent-heuristic

Activer l’heuristique qui décale les limites des sections de diff pour rendre les rustines plus faciles à lire. C’est l’option par défaut.

--no-indent-heuristic

Désactiver l’heuristique d’indentation.

--minimal

Passer plus de temps pour s’assurer que le diff le plus petit possible est produit.

--patience

Générer un diff en utilisant l’algorithme « patience diff ».

--histogram

Générer un diff en utilisant l’algorithme « diff histogramme ».

--anchored=<texte>

Générer un diff en utilisant l’algorithme « diff ancré ».

Cette option peut être spécifiée plus d’une fois.

Si une ligne existe dans la source et la destination, n’existe qu’une seule fois, et démarre avec ce texte, cet algorithme tente d’empêcher qu’elle apparaisse comme une suppression ou une addition dans la sortie. L’algorithme « patience diff » est utilisé en interne.

--diff-algorithm={patience|minimal|histogram|myers}

Choisir un algorithme de diff. Les variantes sont comme suit :

default, myers: L’algorithme de diff avide. C’est actuellement celui par défaut.
minimal: Passer plus de temps pour s’assurer que le diff le plus petit possible est produit.
patience: Utiliser l’algorithme « patience diff » pour la génération de rustine.
histogram: Cet algorithme étend l’algorithme patience pour « supporter les éléments communs de faible fréquence ».

Par exemple, si vous avez configuré la variable diff.algorithm à une valeur autre que celle par défaut et souhaitez utiliser la valeur par défaut, alors vous devez utiliser l’option --diff-algorithm=default.

--stat[=<largeur>[,<largeur-de-nom>[,<nombre>]]]

Générer un diffstat. Par défaut, autant d’espace que nécessaire sera utilisé pour la partie du nom de fichier et le reste pour la partie de graphe. La largeur maximum est par défaut la largeur du terminal, ou 80 colonnes si non connecté à un terminal, et peut être outrepassé avec <largeur>. La largeur du nom de fichier peut être limitée en fournissant une autre largeur <largeur-de-nom> après une virgule. La largeur de la partie du graphe peut être limitée en utilisant --stat-graph-width=<largeur> (affecte toutes les commandes générant un graphe de stat) ou en réglant diff.statGraphWidth=<largeur> (n’affecte pas git format-patch). En ajoutant un troisième paramètre <nombre>, vous pouvez limiter la sortie aux premières <nombre> lignes, suivies de ... s’il y en a plus.

Ces paramètres peuvent aussi être positionnés individuellement avec --stat-width=<largeur>, --stat-name-width=<largeur-de-nom> et --stat-count=<nombre>.

--compact-summary

Afficher un résumé condensé de l’information d’entête étendu telle que les créations ou les suppressions de fichier (« nouveau » ou « disparu », optionnellement « +l » si c’est un lien symbolique) et les modifications de mode (« +x » ou « -x » pour l’ajout et la suppression du bit exécutable respectivement) dans le diffstat. L’information est affichée entre la partie nom de fichier et la partie graphe. Implique --stat.

--numstat

Similaire à --stat, mais afficher le nombre de lignes ajoutées ou supprimées en notation décimale et le nom de chemin sans abréviation, pour le rendre plus facile à traiter automatiquement. Pour les fichiers binaires, affiche deux - au lieu de 0 0.

--shortstat

N’affiche que la dernière ligne du format --stat contenant le nombre total de fichiers modifiés, de même que le nombre de lignes ajoutées et supprimées.

-X[<param1,param2,…>]

--dirstat[=<param1,param2,…>]

Afficher la distribution de la quantité relative de modifications pour chaque sous-répertoire. Le comportement de --dirstat peut être personnalisé en lui passant une liste de paramètres séparés par des virgules. Les valeurs par défaut sont contrôlées par la variable de configuration diff.dirstat (voir git-config[1]). Les paramètres suivants sont disponibles :

changes: Calculer les valeurs de dirstat en comptant les lignes supprimées de la source ou ajoutées dans la destination. Ceci ignore la quantité de purs mouvements de code dans un fichier. En d’autres termes, le réarrangement de lignes dans un fichier n’est pas compté autant que les autres modifications. C’est le comportement par défaut quand aucun paramètre n’est fourni.
lines: Calculer les valeurs dirstat en faisant l’analyse diff normal par ligne, et en additionnant les totaux de lignes ajoutées/supprimées. (Pour les fichiers binaires, compter plutôt les sections de 64 octets, puisque les fichiers binaires n’ont pas de concept de ligne). C’est un comportement de --dirstat plus onéreux que le comportement changes, mais il compte les lignes réarrangées dans un fichier autant que les autres modifications. La sortie résultante est cohérente avec ce que vous obtiendriez avec d’autres options --*stat.
files: Calculer les valeurs dirstat en comptant le nombre de fichiers changés. Chaque fichier modifié compte de façon égale dans l’analyse dirstat. C’est le comportement --dirstat le moins cher en termes de calcul, puisqu’il n’a pas du tout besoin d’analyser le contenu du fichier.
cumulative: Compter les modifications dans un répertoire enfant pour le répertoire parent. Notez qu’en utilisant cumulative, la somme des pourcentages constatés peut dépasser 100 %. Le comportement par défaut (non cumulatif) peut être spécifié avec le paramètre noncumulative.
<limite>: Un paramètre entier qui spécifie un pourcentage limite (3% par défaut). Les répertoires contribuant moins que ce pourcentage de modifications ne sont pas affichés dans la sortie.

Exemple : ce qui suit va compter les fichiers modifiés, tout en ignorant les répertoires qui contiennent moins de 10 % de la quantité totale de fichiers modifiés et en accumulant les totaux des répertoires enfants dans les répertoires parents : --dirstat=files,10,cumulative.

--cumulative

Synonyme de --dirstat=cumulative

--dirstat-by-file[=<param1,param2>…]

Synonyme de --dirstat=files,param1,param2….

--summary

Afficher un résumé condensé d’information d’entête étendu tel que les créations, les renommages et les modifications de mode.

--patch-with-stat

Synonyme de -p --stat.

-z

Séparer les commits avec des NULs au lieu de retours chariot.

Aussi, quand --raw ou --numstat ont été fournis, ne pas modifier les noms de chemins et utiliser des NULs comme terminateurs de champs.

Sans cette option, les noms de chemin avec des caractères « inhabituels » sont cités comme expliqué pour la variable de configuration core.quotePath (voir git-config[1]).

--name-only

N’afficher que les noms des fichiers modifiés.

--name-status

N’afficher que les noms et statuts des fichiers modifiés. Voir la description de l’option --diff-filter pour la signification des lettres de statut.

--submodule[=<format>]

Spécifier comment les différences dans les sous-modules sont affichées. Lorsque vous spécifiez --submodule=short, le format short (court) est utilisé. Ce format n’affiche que le nom des commits du début et de la fin de la plage. Quand --submodule ou --submodule=log est spécifié, le format log (journal) est utilisé. Ce format liste les commits dans la plage comme le fait summary de git-submodule[1]. Quand --submodule=diff est spécifié, le format diff est utilisé. Ce format affiche une diff en ligne des modifications dans le sous-module pour la plage de commits. Vaut par défaut diff.submodule ou le format short si l’option de configuration n’est pas renseignée.

--color[=<quand>]

Afficher des diff colorés. --color (sans =<quand>) est identique à --color=always. <quand> peut être always, never ou auto.

--no-color

Désactiver les diff colorés. C’est identique à --color=never.

--color-moved[=<mode>]

Les lignes de code déplacées sont colorées différemment. Le <mode> vaut par défaut no si l’option n’est pas fournie et zebra si l’option est fournie sans mode. Le mode est une valeur parmi :

no: Les lignes déplacées ne sont pas surlignées.
default: C’est un synonyme de zebra. Cela peut changer pour un mode plus raisonnable dans le futur.
plain: Toute ligne qui est ajoutée à un endroit et supprimée à un autre endroit sera colorée avec color.diff.newMoved. Similairement color.diff.oldMoved sera utilisé pour les lignes retirées qui ont été ajoutées ailleurs dans le diff. Ce mode prend n’importe quelle ligne déplacée, mais il n’est pas très utile dans une revue pour déterminer si un bloc de code a été déplacé sans permutation.
blocks: Les blocs de texte déplacé d’au moins 20 caractères alphanumériques sont détectés avidement. Les blocs détectés sont peints avec les couleurs color.diff.oldMoved pour l’ancienne place et color.diff.newMoved pour la nouvelle place. Les blocs adjacents ne peuvent pas être différenciés.
zebra: Les blocs de texte déplacé sont détectés comme dans le mode blocks. Les blocs sont peints en utilisant la couleur color.diff.{old,new}Moved ou color.diff.{old,new}MovedAlternative. La différence entre les deux couleurs indique qu’un nouveau bloc a été détecté.
dimmed-zebra: Similaire à zebra, mais avec une limitation supplémentaire des parties inintéressantes du code déplacé. Les lignes de frontière de deux blocs adjacents sont considérées intéressantes, le reste est inintéressant. dimmed_zebra est un synonyme déconseillé.

--no-color-moved

Désactiver la détection de déplacement. Ce peut être utilisé pour outrepasser les réglages de configuration. C’est comme --color-moved=no.

--color-moved-ws=<modes>

Ceci configure comment les espaces sont ignorés lors de la détection de déplacement par --color-moved. Ces modes peuvent être fournis comme une liste séparée par des virgules :

no: Ne pas ignorer les espaces lors de la détection de déplacement.
ignore-space-at-eol: Ignorer les modifications d’espaces en fin de ligne.
ignore-space-change: Ignorer les modifications de nombre d’espaces. Cela ignore les espaces en fin de ligne et considère toutes les autres séquences d’un caractère blanc ou plus comme équivalentes.
ignore-all-space: Ignorer les espaces lors de la comparaison de lignes. Ceci ignore les différences même si une ligne a des espaces quand l’autre n’en a aucun.
allow-indentation-change: Ignorer initialement tout espace lors de la détection de déplacement, puis grouper les blocs de code déplacé dans un bloc si la modification de blancs est identique par ligne. C’est incompatible avec les autres modes.

--no-color-moved-ws

Ne pas ignorer les blancs lors de la détection de déplacement. Ceci peut être utilisé pour outrepasser les réglages de configuration. C’est identique à --color-moved-ws=no.

--word-diff[=<mode>]

Afficher un diff par mot, en utilisant le <mode> pour délimiter les mots modifiés. Par défaut, les mots sont délimités par des espaces ; voir --word-diff-regex ci-dessous. Le <mode> vaut par défaut plain, et peut valoir :

color: Surligner les mots modifiés en n’utilisant que des couleurs. Implique --color.
plain: Afficher les mots comme [-supprimé-] et {+ajouté+}. Ne pas tenter d’échapper ces délimiteurs s’ils apparaissent dans l’entrée, donc la sortie peut être ambigüe.
porcelain: Utiliser un format spécial ligne par ligne destiné à la consommation par script. Les séquences ajoutées/supprimées/non-modifiées sont affichées dans le format diff unifié habituel, commençant par un caractère +/-/` ` en début de ligne et en étendant en fin de ligne. Les retours chariot dans l’entrée sont représentés par un tilde ~ sur une ligne à part.
none: Désactiver à nouveau la diff par mots.

Notez qu’en dépit du nom du premier mode, la couleur est utilisée pour surligner les parties modifiées dans tous les modes, si activée.

--word-diff-regex=<regex>

Utiliser <regex> pour décider ce qu’est un mot, au lieu de définir un mot comme une séquence continue de caractères non blancs. Implique aussi --word-diff à moins qu’elle ait déjà été spécifiée.

Toutes correspondances de <regex> qui ne se chevauchent pas sont considérées comme des mots. Tout ce qui se situe entre ces correspondances est considéré comme de l’espace blanc et ignoré (!) lors du calcul de différences. Vous voudrez peut-être ajouter |[^[:space:]] à l’expression régulière pour être sûr qu’elle englobe tous les caractères non blancs. Une correspondance qui contient un retour à la ligne est tronquée silencieusement (!) au retour à la ligne.

Par exemple, --word-diff-regex=. va traiter chaque caractère comme un mot et de ce fait présenter les différences caractère par caractère.

La regex peut aussi être indiquée par un pilote de diff ou une option de configuration, voir gitattributes[5] ou git-config[1]. La ligne de commande a précédence sur le pilote de diff ou la configuration. Le pilote de diff a précédence sur l’option de configuration.

--color-words[=<regex>]

Équivalent à --word-diff=color plus (si une regex a été spécifiée) --word-diff-regex=<regex>.

--no-renames

Désactiver la détection de renommage, même si le fichier de configuration indique de le faire par défaut.

--[no-]rename-empty

S’il faut utiliser les blobs vides comme source de renommage.

--check

Avertir si les modifications introduisent des marqueurs de conflit ou des erreurs d’espaces. Les erreurs d’espaces sont définies par l’option de configuration core.whitespace. Par défaut, les espaces en fin de ligne (incluant les lignes ne contenant que des espaces) et le caractère espace suivi immédiatement par une tabulation lors d’une indentation initiale de ligne sont considérés comme des erreurs d’espace. Le code d’erreur de sortie est non nul en cas de problèmes trouvés. Non compatible avec --exit-code.

--ws-error-highlight=<sorte>

Surligner les erreurs d’espace dans les lignes context (contexte), old (ancien) et new (nouveau) du diff. Des valeurs multiples sont séparées par des virgules, none réinitialise les valeurs précédentes, default réinitialise la liste à new et all est un raccourci pour old,new,context. Quand cette option n’est pas fournie et que la variable de configuration diff.wsErrorHighlight n’est pas assignée, seules les erreurs d’espace dans les lignes new sont surlignées. Les erreurs d’espace sont colorées avec color.diff.whitespace.

--full-index

Au lieu de montrer quelques-uns des premiers caractères, montrer les noms complets des objets blob des images pré et post sur la ligne d’index lors de la génération de la sortie au format patch.

--binary

En plus de --full-index, afficher un diff binaire qui peut être appliqué avec git-apply. Implique --patch.

--abbrev[=<n>]

Au lieu de montrer le nom de l’objet avec les 40 caractères hexadécimaux dans le format de diff brut et les lignes d’entête de l’arbre de diff, ne montrer qu’un préfixe partiel. C’est indépendant de l’option --full-index ci-dessus, qui contrôle le format de sortie de la rustine diff. Un nombre de chiffres différent de celui par défaut peut être spécifié avec --abbrev=<n>.

-B[<n>][/<m>]

--break-rewrites[=[<n>][/<m>]]

Casser les modifications de réécriture complète en paires de suppression et création. Cela sert deux objectifs :

Cela affecte la façon dont un changement qui équivaut à une réécriture totale d’un fichier apparaît non pas comme une série de suppressions et d’insertions mélangées avec quelques lignes qui (par hasard) correspondent entre les deux versions comme contexte, mais comme une simple suppression de tout ce qui est ancien suivi d’une simple insertion de tout ce qui est nouveau, et le nombre m contrôle cet aspect de l’option -B (par défaut 60 %). -B/70% spécifie que moins de 30 % de l’original doit rester dans le résultat pour que Git le considère comme une réécriture totale (autrement, la rustine résultante sera une série de suppressions et d’insertions mélangées avec des lignes de contexte).

Utilisé avec -M, un fichier complètement réécrit est aussi considéré comme la source d’un renommage (habituellement -M ne considère que les fichiers qui ont disparu comme source de renommage), et le nombre n contrôle le niveau de l’option -B (par défaut, 50 %). -B20% signifie qu’une modification avec des additions et des suppressions représentant 20 % ou plus du contenu du fichier est considérée pour être utilisée comme une source possible pour un renommage en un autre fichier.

-M[<n>]

--find-renames[=<n>]

Si des diffs sont générés, détecter et afficher les renommages pour chaque commit. Pour suivre les fichiers au fil des renommages qui apparaissent dans l’historique, voir --follow. Si n est spécifié, c’est un seuil d’index de similarité (c-à-d la quantité d’addition/suppression comparé à la taille du fichier). Par exemple, -M90% signifie que Git considérera un couple suppression/ajout comme renommage si plus de 90 % du fichier n’a pas changé. Sans le signe %, le nombre doit être lu comme une fraction précédée du point décimal. -M5 devient 0,5, tout comme -M50%. De même, -M05 est identique à -M5%. Pour limiter la détection à des renommages exacts, utilisez -M100%. L’index de similarité par défaut est 50%.

-C[<n>]

--find-copies[=<n>]

Détecter les copies aussi bien que les renommages. Voir aussi --find-copies-harder. Si n est spécifié, il a la même signification que pour -M<n>.

--find-copies-harder

Pour des raisons de performance, par défaut, l’option -C trouve des copies seulement si le fichier original de la copie a été modifié dans le même ensemble de modifications. Ce drapeau fait inspecter à la commande les fichiers non modifiés comme candidats comme source de copie. C’est une opération très chère pour des projets importants, donc à utiliser avec précaution. Spécifier plusieurs fois l’option -C a le même effet.

-D

--irreversible-delete

Omettre la pré-image pour des suppressions, c-à-d n’afficher que l’entête mais pas la diff entre la pré-image et /dev/null. La rustine résultante n’est pas destinée à être appliquée avec patch ou git apply ; C’est seulement pour les personnes qui veulent juste se concentrer sur une revue des modifications. De plus, la sortie manque clairement d’assez d’information pour appliquer la rustine en inverse, même manuellement, d’où le nom de l’option.

Lorsqu’utilisé conjointement avec -B, omettre aussi la pré-image dans la partie suppression d’une paire suppression/création.

-l<num>

Les options -M et -C nécessitent un temps de traitement en O(n²) où n est le nombre de cibles potentielles renommage/copie. Cette option empêche l’utilisation de la détection de renommage/copie si le nombre de cibles de renommage/copie excède le nombre indiqué.

--diff-filter=[(A|C|D|M|R|T|U|X|B)…[*]]

Sélectionner seulement les fichiers qui sont Ajoutés (A), Copiés (C), supprimés (Deleted D), Modifiés (M), Renommés (R), ont eu un changement de Type (T) (c-à-d fichier normal, lien symbolique, sous-module …), sont non fusionnés (Unmerged U), sont inconnus (Unknown X) ou ont eu leur appairage cassé (Broken B). Toute combinaison de caractères de filtre (incluant aucun) peut être utilisée. Quand * (Tout-ou-rien) est ajouté à la combinaison, tous les chemins sont sélectionnés s’il y a des fichiers qui correspondent aux autres critères dans la comparaison ; s’il n’y a aucun fichier qui correspond aux autres critères, rien n’est sélectionné.

Aussi, ces lettres majuscules peuvent être spécifiées en minuscules pour exclure. Par exemple, --diff-filter=ad exclut les chemins ajoutés et supprimés.

Notez que toutes les diffs ne peuvent pas présenter tous les types. Par exemple, les diffs de l’index par rapport à l’arbre de travail ne peuvent jamais avoir des entrées Ajoutées (parce que l’ensemble des chemins inclus dans le diff est limité par ce qui est présent dans l’index). Similairement, les entrées copiées et renommées ne peuvent pas apparaître si la détection de ces types est désactivée.

-S<chaîne>

Trouver des différences qui modifient le nombre d’occurrences de la chaîne spécifiée (par ex. addition/suppression) dans un fichier. Destiné à l’usage dans des scripts.

C’est utile lorsqu’on cherche un bloc exact de code (comme une struct), et qu’on veut connaître l’historique de ce bloc depuis son apparition : utiliser cette fonctionnalité itérativement pour fournir le bloc d’une pré-image à -S et continuer jusqu’à obtenir la toute première version du bloc.

Les fichiers binaires sont aussi analysés.

-G<regex>

Rechercher des différences dont le texte de rustine contient les lignes ajoutées/supprimées correspondant à <regex>.

Pour illustrer la différence entre -S<regex> --pickaxe-regex et -G<regex>, considérons un commit contenant la diff suivante dans un même fichier :

+    return frotz(nitfol, two->ptr, 1, 0);
...
-    hit = frotz(nitfol, mf2.ptr, 1, 0);

Alors que git log -G"frotz\(nitfol" affichera ce commit, git log -S"frotz\(nitfol" --pickaxe-regex ne l’affichera pas (parce que le nombre d’occurrences de cette chaîne n’a pas changé).

À moins que --text soit fourni, les rustines de fichiers binaires sans filtre textconv seront ignorées.

Voir l’entrée pickaxe dans gitdiffcore[7] pour plus d’information.

--find-object=<id-objet>

Rechercher les différences qui modifient le nombre d’occurrences de l’objet indiqué. Similaire à -S, juste que l’argument est différent en ce qu’elle ne cherche pas une chaîne particulière mais un identifiant d’objet particulier.

L’objet peut être un commit de blob ou de sous-module. Cela implique l’option -t dans git-log pour trouver aussi des arbres.

--pickaxe-all

Quand -S ou -G trouvent une modification, afficher toutes les modifications dans l’ensemble de modifications, pas seulement les fichiers qui contiennent la modification dans <chaîne>.

--pickaxe-regex

Traiter la <chaîne> fournie à -S comme une expression régulière POSIX étendue à faire correspondre.

-O<fichier-d-ordre>

Contrôler l’ordre dans lequel les fichiers apparaissent dans la sortie. Ceci passe outre la variable de configuration diff.orderFile (voir git-config[1]). Pour annuler diff.orderFile, utiliser -O/dev/null.

L’ordre en sortie est déterminé par l’ordre des motifs glob dans <fichier-d-ordre>. Tous les fichiers dont le nom de chemin correspond au premier motif sont affichés en premier, tous les fichiers dont le nom de chemin correspond au second motif (mais pas au premier) sont affichés ensuite, et ainsi de suite. Tous les fichiers dont les noms de chemin qui ne correspondent à aucun motif sont affichés en dernier, comme s’il y avait un motif ramasse-tout à la fin du fichier. Si de multiples noms de chemin ont le même rang (ils correspondent avec le même motif mais pas de motifs antérieurs), leur ordre relatif d’affichage est l’ordre normal.

<fichier-d-ordre> est analysé comme suit :

Les lignes blanches sont ignorées, de sorte qu’elles peuvent être utilisées comme séparateurs pour la lisibilité.
Les lignes commençant par un dièse ("#") sont ignorées, elles peuvent donc être utilisées comme commentaires. Ajoutez une barre oblique inverse ("\") au début du motif s’il doit commencer par un dièse.
Toutes les autres lignes contiennent un motif unique.

Les motifs ont la même syntaxe et sémantique que les motifs utilisés pour fnmatch(3) sans le drapeau FNM_PATHNAME, sauf qu’un nom de chemin correspond aussi à un motif si la suppression de n’importe quel nombre de composants finaux du nom de chemin correspond au motif. Par exemple, le motif "foo*bar" correspond à "fooasdfbar" et "foo/bar/baz/asdf" mais pas à "foobarx".

-R

Échanger deux entrées ; c’est-à-dire afficher les différences depuis l’index ou avec un fichier sur disque avec le contenu de l’arbre.

--relative[=<chemin>]

--no-relative

Lorsque lancé depuis un sous-répertoire du projet, il peut lui être indiqué d’exclure les modifications hors du répertoire et d’afficher les noms de chemins relativement à lui avec cette option. Quand vous n’êtes pas dans un sous-répertoire (par ex. dans un dépôt nu), vous pouvez nommer quel sous-répertoire par rapport auquel afficher la sortie en fournissant un argument <chemin>. L’option --no-relative peut être utilisée pour annuler l’option de configuration diff.relative et l’option --relative précédente.

-a

--text

Traiter tous les fichiers comme texte.

--ignore-cr-at-eol

Ignorer les retours chariot en fin de ligne lors de la comparaison.

--ignore-space-at-eol

Ignorer les modifications d’espaces en fin de ligne.

-b

--ignore-space-change

Ignorer les modifications de nombre d’espaces. Cela ignore les espaces en fin de ligne et considère toutes les autres séquences d’un caractère blanc ou plus comme équivalentes.

-w

--ignore-all-space

Ignorer les blancs lors de la comparaison de lignes. Ceci ignore les différences même si une ligne contient des espaces alors que l’autre n’en a pas.

--ignore-blank-lines

Ignorer les modifications dont les lignes sont blanches.

--inter-hunk-context=<lignes>

Afficher le contexte entre des sections de diff, jusqu’au nombre spécifié de lignes, fusionnant de ce fait les sections qui sont proches. Par défaut, diff.interHunkContext ou 0 si l’option de configuration n’est pas configurée.

-W

--function-context

Afficher le corps des fonctions englobant les modifications.

--ext-diff

Permettre l’exécution d’un assistant externe de différence. Si vous définissez un pilote externe de différence avec gitattributes[5], vous avez besoin d’utiliser cette option avec git-log[1] et compagnie.

--no-ext-diff

Désactiver les pilotes de diff externes.

--textconv

--no-textconv

Permettre (ou désactiver) le lancement des filtres externes de conversion en texte lors de la comparaison de fichiers binaires. Voir gitattributes[5] pour plus de détails. Comme les filtres textconv sont typiquement des conversions à sens unique, la diff résultante est adaptée à la consommation humaine, mais ne peut pas être appliquée. Pour cette raison, les filtres textconv sont activés par défaut seulement pour git-diff[1] et git-log[1], mais pas pour git-format-patch[1] ou les commandes de plomberie de diff.

--ignore-submodules[=<quand>]

Ignorer les modifications à des sous-modules lors de la génération du diff. <quand> peut valoir "none" (aucun), "untracked" (non-suivi), "dirty" (sale) ou "all" (tout) qui est la valeur par défaut. L’utilisation de "none" va considérer comme modifiés les sous-modules quand ils contiennent soit des fichiers non-suivis ou modifiés, ou si sa HEAD diffère du commit enregistré dans le super-projet, et peut être utilisé pour passer outre tout réglage de l’option ignore dans git-config[1] ou gitmodules[5]. Quand "untracked" est utilisé, les sous-modules ne sont pas considérés sales quand ils ne contiennent que du contenu non suivi (mais ils sont quand même scannés pour trouver du contenu modifié). L’utilisation de "dirty" ignore toutes les modifications à l’arbre de travail des sous-modules ; seules les modifications aux commits stockés dans le super-projet sont affichées (c’était le comportement jusqu’à 1.7.0). La valeur "all" cache toutes les modifications des sous-modules.

--src-prefix=<préfixe>

Afficher le préfixe de source fourni au lieu de "a/".

--dst-prefix=<préfixe>

Afficher le préfixe de destination fourni au lieu de "b/".

--no-prefix

N’afficher aucun préfixe ni de source, ni de destination.

--line-prefix=<préfixe>

Préfixer avec une chaîne additionnelle chaque ligne de la sortie.

--ita-invisible-in-index

Par défaut, une entrée ajoutée par "git add -N" apparaît comme un fichier vide existant dans "git diff" et un nouveau fichier dans "git diff --cached". Cette option fait apparaître l’entrée comme un fichier nouveau dans "git diff" et non existant dans "git diff --cached". Cette option peut être inversée avec --ita-visible-in-index. Les deux options sont expérimentales et peuvent être retirées dans le futur.

Pour une explication plus détaillée sur ces options communes, voir aussi gitdiffcore[7].

Génération du texte de rustine avec -p

Exécuter git-diff[1], git-log[1], git-show[1], git-diff-index[1], git-diff-tree[1] ou git-diff-files[1] avec l’option -p produit le texte de rustine. Vous pouvez personnaliser la création du texte de rustine via les variables d’environnement GIT_EXTERNAL_DIFF et GIT_DIFF_OPTS.

L’option produit quelque chose légèrement différent du format diff traditionnel :

Il est précédé d’un entête "git diff" qui ressemble à ceci :
```
diff --git a/fichier1 b/fichier2
```
les noms de fichiers sous a/ et b/ sont identiques à moins qu’il y ait eu un renommage ou une copie, même pour un création ou une suppression, /dev/null n’est pas utilisé à la place des noms de fichier a/ ou`b/`.

Quand un renommage ou un copie est décrit, fichier1 et fichier2 indiquent les noms du fichier source et du fichier cible, respectivement.
Suivent un ligne ou plus d’entête étendu :
```
old mode <mode>
new mode <mode>
deleted file mode <mode>
new file mode <mode>
copy from <chemin>
copy to <chemin>
rename from <chemin>
rename to <chemin>
similarity index <nombre>
dissimilarity index <nombre>
index <empreinte>..<empreinte> <mode>
```
Les modes de fichier sont affichés comme des nombres à 6 chiffres en octal incluant le type de fichier et les bits de permission.

Les noms de chemin dans les entêtes étendus n’incluent pas les préfixes a/ et b/.

L’index de similarité et le pourcentage de lignes inchangées et l’index de dissimilarité est le pourcentage de lignes changées. Il est arrondi à l’entier inférieur, suivi du signe pourcent. Une valeur d’index de similarité à 100 % correspond donc à deux fichiers identiques, tandis qu’un index de dissimilarité de 100 % signifie qu’aucune ligne de l’ancien fichier ne se retrouve dans le nouveau fichier.

La ligne d’index inclut les noms des objets blob avant et après la modification. Le <mode> est inclus si le mode du fichier n’est pas modifié ; sinon, des lignes séparées indiquent l’ancien et le nouveau mode.
Les noms de chemin avec des caractères « inhabituels » sont cités comme expliqué pour la variable de configuration core.quotePath (voir git-config[1]).
Tous les fichiers fichier1 de la sortie font référence à des fichiers avant la validation, et tous les fichiers fichier2 font référence aux fichiers après la validation. Il est incorrect d’appliquer chaque modification à chaque fichier séquentiellement. Par exemple, cette rustine échange a et b :
```
diff --git a/a b/b
rename from a
rename to b
diff --git a/b b/a
rename from b
rename to a
```

Format de diff combiné

Toute commande générant un diff accepte l’option -c ou -cc pour produire un diff combiné lors de l’affichage d’une fusion. C’est le format par défaut pour afficher les fusions avec git-diff[1] ou git-show[1]. Notez aussi que vous pouvez ajouter l’option -m à toutes ces commandes pour forcer la génération des diffs avec un parent individuel d’une fusion.

Un format de diff combiné ressemble à ceci :

diff --combined describe.c
index fabadb8,cc95eb0..4866510
--- a/describe.c
+++ b/describe.c
@@@ -98,20 -98,12 +98,20 @@@
	return (a_date > b_date) ? -1 : (a_date == b_date) ? 0 : 1;
  }

- static void describe(char *arg)
 -static void describe(struct commit *cmit, int last_one)
++static void describe(char *arg, int last_one)
  {
 +	unsigned char sha1[20];
 +	struct commit *cmit;
	struct commit_list *list;
	static int initialized = 0;
	struct commit_name *n;

 +	if (get_sha1(arg, sha1) < 0)
 +		usage(describe_usage);
 +	cmit = lookup_commit_reference(sha1);
 +	if (!cmit)
 +		usage(describe_usage);
 +
	if (!initialized) {
		initialized = 1;
		for_each_ref(get_name);

Il est précédé d’un entête "git diff", qui ressemble à ceci (quand l’option -c est utilisée) :
```
diff --combined file
```
ou à ceci (lorsque l’option --cc est utilisée) :
```
diff --cc file
```
Il est suivi par une ligne d’entête étendu ou plus (cet exemple montre une fusion avec deux parents) :
```
index <empreinte>,<empreinte>..<empreinte>
mode <mode>,<mode>..<mode>
new file mode <mode>
deleted file mode <mode>,<mode>
```
La ligne mode <mode>,<mode>..<mode> n’apparaît que si au moins un des modes est différent du reste. Les entêtes étendus avec l’information à propos des déplacements détectés de contenu (détection de renommages et de copies) sont conçus pour fonctionner avec le diff de deux <arbre-esques> et ne sont pas utilisés dans le format de diff combiné.
Il est suivi par un entête de deux lignes fichier-source/fichier-cible
```
--- a/fichier
+++ b/fichier
```
Similaire à l’entête à deux lignes pour le format diff unifié traditionnel, /dev/null est utilisé pour indiquer un fichier créé ou supprimé.

Cependant, si l’option --combined-all-paths est fournie, au lieu des deux lignes de fichier-source/fichier-cible, vous obtenez un en-tête de N+1 lignes de fichier-source/fichier-cible, où N est le nombre de parents dans le commit de fusion
```
--- a/fichier
--- a/fichier
--- a/fichier
+++ b/fichier
```
Ce format étendu peut être utile si la détection de renommage ou de copie est active, pour vous permettre de voir le nom original du fichier dans différents parents.
Le format d’entête de section est modifié pour empêcher l’utilisation accidentelle avec patch -p1. Le format de diff combiné a été créé pour les revues des modifications de commits de fusions, et n’était pas destiné à être appliqué. La modification est similaire à la modification dans l’entête étendu d’index :
```
@@@ <intervalle-de-fichier-source> <intervalle-de-fichier-source> <intervalle-de-fichier-cible> @@@
```
Il y a (nombre de parents + 1) caractères @ dans l’entête de section pour le format de diff combiné.

À la différence du format diff unifié traditionnel qui montre deux fichiers A et B avec une seule colonne qui a un préfixe - (moins — apparaît dans A mais supprimé dans B), + (plus — manquant dans A mais ajouté dans B), ou " " (espace — non modifié), ce format compare un fichier ou plus fichier1, fichier2,… avec un fichier X, et affiche comment X diffère de chaque fichierN. Une colonne pour chaque fichierN est insérée dans la sortie pour montrer comment la ligne de X est différente de la ligne correspondante de celui-ci.

Un caractère - dans la colonne N signifie que la ligne apparaît dans fichierN mais pas dans le résultat. Un caractère + dans la colonne N signifie que la ligne apparaît dans le résultat, et fichierN ne l’a pas (en d’autres termes, la ligne a été ajoutée du point de vue de ce parent).

Dans l’exemple de sortie ci-dessus, la signature de la fonction a été changée depuis les deux fichiers (d’où les deux suppressions - depuis fichier1 et fichier2, plus ++ pour signifier qu’une ligne qui a été ajoutée n’apparaît ni dans fichier1 ni dans fichier2). De plus, huit autres lignes sont identiques depuis fichier1 mais n’apparaissent pas dans fichier2 (et sont donc préfixées par +).

Quand affiché par git diff-tree -c, les parents du commit de fusion sont comparés avec le résultat de fusion (c-à-d fichier1..fichierN sont les parents) ; Quand affiché par git diff-files -c, les deux parents de fusion non résolue sont comparés avec le fichier dans l’arbre de travail (c-à-d fichier1 est stage 2, « notre version », fichier2 est stage 3, « leur version »).

EXEMPLES

git log --no-merges: Affiche tout l’historique des commits, mais saute toutes les fusions
git log v2.6.12.. include/scsi drivers/scsi: Affiche tous les commits depuis la version v2.6.12 qui a modifié n’importe quel fichier dans les sous-directeurs include/scsi ou drivers/scsi
git log --since="2 weeks ago" -- gitk: Affiche les modifications au cours des deux dernières semaines au fichier gitk. Le -- est nécessaire pour éviter toute confusion avec la branche nommée 'gitk
git log --name-status release..test: Affiche les commits qui se trouvent dans la branche "test" mais pas encore dans la branche "libération", ainsi que la liste des chemins que chaque commit modifie.
git log --follow builtin/rev-list.c: Affiche les commits qui ont changé builtin/rev-list.c, y compris les commits qui se sont produits avant que le fichier ne soit appelé par son nom actuel.
git log --branches --not --remotes=origin: Affiche tous les commits qui sont dans l’une des branches locales, mais pas dans l’une des branches de suivi à distance pour « origin » (ce que vous avez que cette origine n’est pas).
git log master --not --remotes=*/master: Affiche tous les commits qui sont dans la branche master locale mais pas dans les branches master du dépôt distant.
git log -p -m --first-parent: Affiche l’historique, y compris les diffs de changement, mais seulement du point de vue de la « branche principale », en sautant les commits qui proviennent de branches fusionnées, et en montrant des diffs complets des changements introduits par les fusions. Cela n’a de sens que lorsqu’il s’agit de suivre une politique stricte de fusion de toutes les branches thématiques lorsqu’on reste sur une seule branche d’intégration.
git log -L '/int main/',/^}/:main.c: Montre comment la fonction main() dans le fichier 'main.c’a évolué au fil du temps.
git log -3: Limite le nombre de commits à afficher à 3.

DISCUSSION

Git est dans une certaine mesure agnostique concernant l’encodage des caractères.

Le contenu des objets blob est une séquence d’octets non interprétés. Il n’y a pas de conversion d’encodage au niveau de base.
Les noms de chemins sont encodés en forme C de normalisation UTF-8. Ceci s’applique aux objets arbre, au fichier d’index, au noms de références ainsi qu’aux noms de chemin en argument de ligne de commande, aux variables d’environnement et aux fichiers de configuration (.git/config (voir git-config[1]), gitignore[5], gitattributes[5] and gitmodules[5]).

Remarquez que Git traite les noms de chemins comme des séquences d’octets non-nuls au niveau de base, il n’y a pas de conversion d’encodage des noms de fichiers (sauf sur Mac et Windows). De ce fait, l’utilisation de noms de chemins non-ASCII fonctionnera pratiquement, même sur les plateformes et systèmes de fichier utilisant d’anciens encodages d’ASCII étendu.
Les messages du journal des validations sont typiquement encodés en UTF-8, mais les autres encodages d’ASCII étendu sont aussi pris en charge. Ceci inclut ISO-8859-x, CP125x et de nombreux autres, mais pas UTF-16/32, EBCDIC ni les encodages multi-octets CJK (GBK, Shift-JIS, Big5, EUC-x, CP9xx etc.).

Bien que l’usage de UTF-8 dans les messages de validation soit encouragé, le cœur de Git et la porcelaine sont conçus pour ne pas forcer l’usage d’UTF-8 dans les projets. Si tous les participants d’un projet donné trouvent plus simple d’utiliser des encodages anciens, Git ne l’interdit pas. Cependant, il y a quelques détails à garder en tête.

git commit et git commit-tree affichent un avertissement si le message de validation fourni ne semble pas être une chaîne de caractères UTF-8 valide, à moins que vous n’indiquiez explicitement que votre projet utilise un encodage ancien. La manière de l’indiquer est d’avoir i18n.commitencoding dans .git/config, comme ceci :
```
[i18n]
	commitEncoding = ISO-8859-1
```
Les objets commit créés avec le réglage ci-dessus enregistrent la valeur de i18n.commitEncoding dans leur entête d’encodage encoding. Ceci permet d’aider les personnes qui les liront plus tard. L’absence de cet entête implique que les message de validation est encodé en UTF-8.
Sauf indication contraire, git log, git show, git blame et consort lisent l’entête encoding d’un objet commit et essaient de ré-encoder le message de validation en UTF-8. Vous pouvez spécifier l’encodage de sortie que vous souhaitez avec i18n.logOutputEncoding dans le fichier .git/config, comme ceci :
```
[i18n]
	logOutputEncoding = ISO-8859-1
```
Si vous n’avez pas changé cette variable de configuration, c’est la valeur de i18n.commitEncoding qui est utilisée.

Remarquez qu’il a été délibérément choisi de ne pas ré-encoder le message de validation quand le commit est créé pour forcer l’UTF-8 au niveau de l’objet commit parce que ré-encoder en UTF-8 n’est pas nécessairement une opération réversible.

CONFIGURATION

Voir git-config[1] pour les variables de base et git-diff[1] pour les paramètres liés à la génération diff.

format.pretty: La valeur par défaut de l 'option - -format.(voir ci-dessus « Mise en forme ») par défaut medium.
i18n.logOutputEncoding: Encodage à utiliser lors de l’affichage des journaux. (Voir Discussion ci-dessus.) Par défaut à la valeur de i18n.commitEncoding si elle est fixée, et UTF-8 autrement.
log.date: Format par défaut pour les dates humainement lisibles. (Compare l’option --date.) Par défaut à "défaut", ce qui signifie écrire des dates comme Sat May 8 19:35:34 2010 -0500.

Si le format est réglé sur "auto:foo" et que le paginateur est utilisé, le format "foo" sera utilisé pour le format de date. Sinon, "default" sera utilisé.
log.follow: Si true, git log agira comme si l’option ‘--follow’ était utilisée lorsqu’un seul <chemin> est donné. Ceci a les mêmes limitations que ‘--follow’, c’est-à-dire qu’il ne peut pas être utilisé pour suivre plusieurs fichiers et ne fonctionne pas bien sur un historique non linéaire.
log.showRoot: Si false, git log et les commandes associées ne traiteront pas le commit initial comme un grand événement de création. Tout commit racine dans la sortie git log -p serait affiché sans diff attaché. La valeur par défaut est true.
log.showSignature: Si true, git log et les commandes associées agiront comme si l’option --show-signature leur était passée.
mailmap.*: Voir git-shortlog[1].
notes.displayRef: Quelles refs, en plus de la définition par défaut par core.notesRef ou GIT-NOTES-REF, depuis lequelles lire les notes lors de l’affichage des messages de validation avec la famille de commandes log. Voir git-notes[1].

Peut être un nom de référence non abrégé ou un glob et peut être spécifié plusieurs fois. Un avertissement sera émis pour les références qui n’existent pas, mais un glob qui ne correspond à aucune référence est ignoré en silence.

Ce paramètre peut être désactivé par l’option --no-notes, remplacé par la variable d’environnement GIT_NOTES_DISPLAY_REF, et remplacé par l’option --notes=<ref>.

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 .

Setup and Config

Getting and Creating Projects

Basic Snapshotting

Branching and Merging

Sharing and Updating Projects

Inspection and Comparison

Patching

Debugging

Email

External Systems

Server Admin

Guides

Administration

Plumbing Commands

NOM