Git
Français ▾ Topics ▾ Latest version ▾ git-rev-list last updated in 2.44.0

NOM

git-rev-list - Affiche les objets commit dans l’ordre chronologique inverse

SYNOPSIS

git rev-list [<options>] <commit> …​[[--] <chemin>…​]

DESCRIPTION

Liste les commits qui sont accessibles en suivant les liens parents du ou des commits donnés, mais exclut les commits qui sont accessibles depuis le ou les commits donnés avec un ^ devant eux. La sortie est donnée dans l’ordre chronologique inverse par défaut.

Vous pouvez considérer cela comme une opération sur un ensemble. Les commits accessibles à partir de n’importe lequel des commits donnés sur la ligne de commande forment un ensemble, puis les commits accessibles à partir de n’importe lequel de ceux donnés avec ^ devant sont soustraits de cet ensemble. Les commits restants sont ceux qui apparaissent dans la sortie de la commande. Diverses autres options et paramètres de chemins peuvent être utilisés pour limiter davantage le résultat.

Ainsi, la commande suivante :

$ git rev-list foo bar ^baz

signifie "liste tous les commits qui sont accessibles depuis foo ou bar, mais pas depuis baz".

Une notation spéciale "<commit1>..<commit2>" peut être utilisée comme raccourci pour "^<commit1> <commit2>". Par exemple, l’un ou l’autre des éléments suivants peut être utilisé de manière interchangeable :

$ git rev-list origin..HEAD
$ git rev-list HEAD ^origin

Une autre notation spéciale est "<commit1>…​<commit2>" qui est utile pour les fusions. L’ensemble de commits résultant est la différence symétrique entre les deux opérandes. Les deux commandes suivantes sont équivalentes :

$ git rev-list A B --not $(git merge-base --all A B)
$ git rev-list A...B

rev-list is a very essential Git command, since it provides the ability to build and traverse commit ancestry graphs. For this reason, it has a lot of different options that enables it to be used by commands as different as git bisect and git repack.

OPTIONS

Limitation de commit

En plus de spécifier une plage de commits qui doivent être listés en utilisant les notations spéciales expliquées dans la description, des limitations supplémentaires de commits peuvent être appliquées.

L’utilisation d’un plus grand nombre d’options filtre généralement plus la sortie (par exemple --since=<date1> limite aux commits plus récents que <date1>, et son utilisation avec --grep=<motif> limite aux commits dont le message de journal a une ligne qui correspond <motif>), sauf indication contraire.

Notez que celles-ci sont appliquées avant les options de classement et de formatage des commits, telles que --reverse.

-<nombre>
-n <nombre>
--max-count==<nombre>

Limite le nombre de commits dans la sortie.

--skip=<nombre>

Sauter’nombre' commits avant de commencer à afficher la sortie de journal.

--since=<date>
--after=<date>

Afficher les commits plus récents qu’une date spécifique.

--since-as-filter=<date>

Afficher tous les commits plus récents qu’une date spécifique. Cela visite tous les commits dans la plage, plutôt que de s’arrêter au premier commit qui est plus ancien qu’une date spécifique.

--until=<date>
--before=<date>

Afficher les commits plus anciens qu’une date spécifique.

--max-age=<horodatage>
--min-age=<horodatage>

Limiter la sortie des commits à une plage de temps spécifiée.

--author=<motif>
--committer=<motif>

Limiter la sortie des commits à ceux dont les lignes d’en-tête auteur/validateur correspondent au motif spécifié (expression régulière). Avec plus d’un --author=<motif>, les commits dont l’auteur correspond à l’un des motifs donnés sont choisis (de même pour plusieurs --committer=<motif>).

--grep-reflog=<motif>

Limiter la sortie des commits à ceux dont les entrées de reflog correspondent au motif spécifié (expression régulière). Avec plus d’un ‘--grep-reflog’, les commits dont le message de reflog correspond à l’un des modèles donnés sont choisis. C’est une erreur d’utiliser cette option à moins que ‘--walk-reflogs’ ne soit utilisé.

--grep=<motif>

Limiter la sortie des commits à ceux dont un message de validation correspond au motif spécifié (expression régulière). Avec plus d’un --grep=<motif>, les commits dont le message correspond à l’un des motifs donnés sont choisis (mais voir --all-match).

--all-match

Limiter la sortie des commits à ceux qui correspondent à la fois à tous les ‘--grep’ donnés, au lieu de ceux qui correspondent à au moins un.

--invert-grep

Limiter la sortie des commits à ceux dont un message de validation ne correspond pas au motif spécifié avec --grep=<motif>.

-i
--regexp-ignore-case

Faites correspondre les expressions régulières sans tenir compte de la casse des lettres.

--basic-regexp

Considérer les motifs limitatifs comme des expressions régulières de base ; c’est la valeur par défaut.

-E
--extended-regexp

Considérer les motifs limitatifs comme des expressions régulières étendues au lieu des expressions régulières par défaut de base.

-F
--fixed-strings

Considérer les motifs limitatifs comme des chaînes de caractères fixes (ne pas interpréter le motif comme une expression régulière).

-P
--perl-regexp

Considérer les motifs limitatifs comme des expressions régulières compatibles Perl.

La prise en charge de ces types d’expressions régulières est une dépendance optionnelle à la compilation. Si Git n’a pas été compilé avec ce support et que cette option est activée, la commande se termine immédiatement.

--remove-empty

Arrêter lorsqu’un chemin donné disparaît de l’arbre.

--merges

N’afficher que les commits de fusion. C’est exactement la même chose que --min-parents=2.

--no-merges

Ne pas afficher les commits avec plus d’un parent. C’est exactement la même chose que --max-parents=1.

--min-parents=<nombre>
--max-parents=<nombre>
--no-min-parents
--no-max-parents

Afficher uniquement les commits qui ont au moins (ou au plus) autant de commits parents. En particulier, --max-parents=1 est la même chose que --no-merges, --min-parents=2 est la même chose que --merges. --max-parents=0 donne tous les commits racine et --min-parents=3 toutes les fusions octopus.

--no-min-parents et --no-max-parents réinitialisent ces limites (à sans limite). Les formes équivalentes sont --min-parents=0 (tout commit a 0 ou plus de parents) et --max-parents=-1 (les nombres négatifs dénotent l’absence de limite supérieure).

--first-parent

Lors de la recherche de commits à inclure, ne suivre que le premier commit parent lors d’un commit de fusion. Cette option peut donner une meilleure vue d’ensemble lors de l’affichage de l’évolution d’une branche de sujet particulière, parce que la fusion dans une branche de sujet a tendance à n’être que des mises à jour avec l’amont de temps en temps, et cette option permet d’ignorer les commits individuels apportés dans votre historique par de telles fusions.

--exclude-first-parent-only

Lors de la recherche de commits à exclure (avec un ^ ;), ne suivre que le premier commit parent lorsqu’un commit de fusion est vu. Cela peut être utilisé pour trouver l’ensemble des changements dans une branche de sujet à partir du point où elle a divergé de la branche distante, étant donné que des fusions arbitraires peuvent être des changements de branches thématiques valides.

--not

Inverse le sens du préfixe ^ (ou son absence) pour tous les spécificateurs de révision suivants, jusqu’au prochain --not. Lorsqu’il est utilisé sur la ligne de commande avant --stdin, les révisions passées par stdin ne seront pas affectées. Inversement, lorsqu’il est passé par l’entrée standard, les révisions passées sur la ligne de commande ne seront pas affectées.

--all

Faire comme si toutes les refs de refs/, ainsi 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, --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.

--exclude-hidden=[fetch|receive|uploadpack]

Ne pas inclure les références qui seraient cachées par git-fetch, git-receive-pack ou git-upload-pack en consultant la configuration fetch.hideRefs, receive.hideRefs ou uploadpack.hideRefs`correspondante ainsi que `transfer.hideRefs (voir git-config[1]). Cette option affecte l’option de pseudo-référence suivante --all ou --glob et est effacée après leur traitement.

--reflog

Faire comme si tous les objets mentionnés par les reflogs étaient listés sur la ligne de commande comme <commit>.

--alternate-refs

Faire comme si tous les objets mentionnés en tant que sommets de référence des dépôts alternatifs étaient listés sur la ligne de commande. Un dépôt alternatif est tout dépôt dont le répertoire d’objets est spécifié dans objects/info/alternates. L’ensemble des objets inclus peut être modifié 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.

--stdin

En plus d’obtenir des arguments de la ligne de commande, les lire aussi depuis l’entrée standard. Cela accepte des commits et des pseudo-options comme --all et --glob=. Lorsqu’un séparateur -- est vu, les entrées suivantes sont traitées comme des chemins et utilisées pour limiter le résultat. Les drapeaux comme --not qui sont lus via l’entrée standard ne sont respectés que pour les arguments passés de la même manière et n’influenceront aucun argument de ligne de commande suivant.

--quiet

Ne rien imprimer en sortie standard. Cette forme est principalement destinée à permettre à l’appelant de tester l’état de sortie pour voir si une série d’objets est entièrement connectée (ou non). C’est plus rapide que de rediriger stdout vers /dev/null car la sortie n’a pas besoin d’être formatée.

--disk-usage
--disk-usage=human

Supprimer la sortie normale ; afficher plutôt la somme des octets utilisés pour le stockage sur disque par les commits ou les objets sélectionnés. Cela équivaut à envoyer la sortie dans git cat-file --batch-check='%(objectsize:disk)', sauf que cela fonctionne beaucoup plus vite (surtout avec --use-bitmap-index). Voir la section AVERTISSEMENTS dans git-cat-file[1] pour les limitations de ce que signifie "stockage sur disque". Avec la valeur optionnelle human, la taille du stockage sur disque est affichée par une chaîne de caractères lisible par l’homme (par exemple 12,24 Kio, 3,50 Mio).

--cherry-mark

Comme --cherry-pick (voir ci-dessous) mais marquer les commits équivalents avec == plutôt que de les omettre, et les différents avec +.

--cherry-pick

Omettre tout commit qui introduit le même changement qu’un autre commit de l'"autre côté" lorsque l’ensemble des commits est limité avec une différence symétrique.

Par exemple, si vous avez deux branches, A et B, une façon habituelle de lister tous les commits d’un seul côté d’entre elles est avec --left-right (voir l’exemple ci-dessous dans la description de l’option --left-right). Cependant, cela montre les commits qui ont été picorés sur l’autre branche (par exemple, “3rd on b” peut être trié sur la branche A). Avec cette option, ces paires de commits sont exclues de la sortie.

--left-only
--right-only

Ne lister que les commits du côté respectif d’une différence symétrique, c’est-à-dire seulement ceux qui seraient marqués < resp. > par --left-right.

Par exemple, --cherry-pick --right-only A...B omet les commits de B qui sont dans A ou sont équivalents en rustine à un commit en A. En d’autres termes, cela liste les commits + de git cherry A B. Plus précisément, --cherry-pick --right-only --no-merges donne la liste exacte.

--cherry

Un synonyme pour --right-only --cherry-mark --no-merges ; utile pour limiter la sortie aux commits de notre côté et marquer ceux qui ont été appliqués de l’autre côté d’un historique en fourche avec git log --cherry amont...mabranche', similaire à `git cherry upstream mabranche.

-g
--walk-reflogs

Au lieu de marcher dans la chaîne des commits ancêtres, parcourir les entrées de reflog du plus récent au plus ancien. Lorsque cette option est utilisée, vous ne pouvez pas spécifier de commits à exclure (c’est-à-dire que les notations ^commit, commit1..commit2 et’commit1...commit2' ne peuvent pas être utilisées).

Avec le format --pretty autre que online et reference (pour des raisons évidentes), cela fait que la sortie a deux lignes supplémentaires d’informations tirées du reflog. L’indicateur de reflog dans la sortie peut être affiché comme ref@{Nième} (où Nième est l’index chronologique inverse dans le reflog) ou comme ref@{horodatage} (avec l’horodatage pour cette entrée), selon quelques règles :

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

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

  3. Si ni l’un ni l’autre n’a été utilisé, mais que --date' a été donné sur la ligne de commande, afficher l'horodatage dans le format demandé par `--date.

  4. Sinon, afficher le format de l’index.

Sous --pretty=oneline, le message de commit est préfixé avec cette information sur la même ligne. Cette option ne peut pas être combinée avec ‘--reverse’. Voir aussi git-reflog[1].

Sous l’option --pretty=reference, ces informations ne seront pas affichées du tout.

--merge

Après une fusion ratée, afficher les références qui touchent les fichiers en conflit et qui n’existent pas sur toutes les têtes à fusionner.

--boundary

Afficher les commits de limite exclus. Les limites sont préfixées par -.

--use-bitmap-index

Essayer d’accélérer la traversée en utilisant l’index bitmap empaqueté (si disponible). Notez que lorsque vous parcourez avec --objects, les arbres et les blobs n’auront pas leur chemin associé affiché.

--progress=<entête>

Afficher les rapports d’avancement sur stderr au fur et à mesure que les objets sont pris en compte. Le texte "<en-tête>" sera affiché à chaque mise à jour de l’état d’avancement.

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[=<commit>]

Lorsque l’on donne une plage de commits à afficher (par exemple commit1..commit2 ou commit2 ^commit1), n’afficher que les commits de cette plage qui sont des ancêtres de <commit>, des descendants de <commit>, ou <commit> lui-même. Si aucun commit n’est spécifié, utiliser commit1 (la partie exclue de la plage) comme <commit>. Peut être passée plusieurs fois ; si c’est le cas, un commit est inclus s’il est l’un des commits donnés ou s’il est un ancêtre ou un descendant de l’un d’eux.

Une explication plus détaillée suit.

Supposons que vous ayez spécifié foo pour <chemins>. Nous appellerons les commits qui modifient foo !MEMEARBRE, et le reste MEMEARBRE. (Dans un diff filtré pour foo, ils sont différents et égaux, respectivement.)

Dans ce qui suit, nous nous référerons toujours au même exemple d’historique pour illustrer les différences entre les paramètres de simplification. Nous supposons que vous filtrez pour un fichier foo dans ce graphe de commits :

	  .-A---M---N---O---P---Q
	 /     /   /   /   /   /
	I     B   C   D   E   Y
	 \   /   /   /   /   /
	  `-------------'   X

La ligne horizontale de l’historique A---Q est prise pour être le premier parent de chaque fusion. Les commits sont :

  • I est le commit initial, dans lequel foo` existe avec le contenu ''asdf', et un 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 avec réécriture des parents

Les commits ordinaires ne sont inclus que s’ils le sont !MEMEARBRE (bien que cela puisse être changé, voir --sparse ci-dessous).

Les fusions sont toujours incluses. Cependant, leur liste de parents est réécrite : à côté de chaque parent, élaguer les commits qui ne sont pas inclus eux-mêmes. Il en résulte

	  .-A---M---N---O---P---Q
	 /     /   /   /   /
	I     B   /   D   /
	 \   /   /   /   /
	  `-------------'

À comparer avec --full-history sans réécrire ci-dessus. Notez 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[=<commit>]

Limiter les commits affichés à ceux qui sont un ancêtre de <commit>, ou qui sont un descendant de <commit>, ou sont <commit> lui-même.

À titre d’exemple, considérons l’historique de commits suivant :

	    D---E-------F
	   /     \       \
	  B---C---G---H---I---J
	 /                     \
	A-------K---------------L--M

Un D..M régulier calcule l’ensemble des commits qui sont les ancêtres de M, mais exclut ceux qui sont les ancêtres 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

Nous pouvons également utiliser --ancestry-path=D au lieu de --ancestry-path qui signifie la même chose lorsqu’il est appliqué à la plage D..M mais est juste plus explicite.

Si nous sommes plutôt intéressés par un sujet donné dans cette plage, et tous les commits affectés par ce sujet, nous pouvons seulement vouloir voir ceux du sous-ensemble de D..M qui contiennent ce sujet dans leur chemin d’ascendance. Ainsi, en utilisant --ancestry-path=H D..M par exemple, on obtiendrait le résultat suivant :

		E
		 \
		  G---H---I---J
			       \
				L--M

Alors que --ancestry-path=K D...M donnerait comme résultat

		K---------------L--M

Avant de discuter d’une autre option, --show-pulls, nous devons créer un nouvel exemple d’historique.

Un problème courant auquel les utilisateurs sont confrontés lorsqu’ils consultent l’historique simplifié est qu’un commit dont ils savent qu’il a modifié un fichier n’apparaît pas dans l’historique simplifié du fichier. Prenons un nouvel exemple et montrons comment des options telles que --full-history et --simplify-merges fonctionnent dans ce cas :

	  .-A---M-----C--N---O---P
	 /     / \  \  \/   /   /
	I     B   \  R-'`-Z'   /
	 \   /     \/         /
	  \ /      /\        /
	   `---X--'  `---Y--'

Pour cet exemple, supposons que I a créé fichier.txt qui a été modifié par A, B et X de différentes manières. Les commits à parent unique C, Z et Y ne modifient pas fichier.txt. Le commit de fusion M a été créé en résolvant le conflit de fusion pour inclure les deux modifications de A et B et n’est donc pas MEMEARBRE pour l’un ou l’autre. Le commit de fusion R, cependant, a été créé en ignorant le contenu du fichier fichier.txt à M et en prenant seulement le contenu du fichier fichier.txt à X. Par conséquent, R est MEMEARBRE à X mais pas à M. Enfin, la résolution de fusion naturelle pour créer N est de prendre le contenu du fichier.txt à R, donc N est MEMEARBRE à R mais pas à C. La fusion engage O et P sont MEMEARBRE à leurs premiers parents, mais pas à leurs seconds parents, Z et Y respectivement.

En utilisant le mode par défaut, N et R ont tous deux un parent MEMEARBRE, donc ces bords sont parcourus et les autres sont ignorés. Le graphique d’historique qui en résulte est :

	I---X

Lors de l’utilisation de --full-history, Git parcourt toutes les arêtes . Il découvrira les commits A et B et la fusion M, mais aussi les commits de fusion O et P. Avec la réécriture des parents, le graphe résultant est :

	  .-A---M--------N---O---P
	 /     / \  \  \/   /   /
	I     B   \  R-'`--'   /
	 \   /     \/         /
	  \ /      /\        /
	   `---X--'  `------'

Ici, les commits de fusion O et P apportent un bruit supplémentaire, car ils n’ont pas réellement apporté de modification à fichier.txt. Ils ont seulement fusionné une branche thématique qui était basée sur une ancienne version de fichier.txt. C’est un problème courant dans les dépôts utilisant une organisation où de nombreux contributeurs travaillent en parallèle et fusionnent leurs branches thématiques le long d’un seul tronc : de nombreuses fusions sans rapport apparaissent dans les résultats de --full-history.

Lorsque l’on utilise l’option --simplify-merges, les valeurs O et P disparaissent des résultats. Cela est dû au fait que les seconds parents réécrits de O et P sont accessibles depuis leurs premiers parents. Ces arêtes sont supprimées et les commits ressemblent alors à des commits monoparentaux qui sont MEMEARBRE pour leur parent. C’est également le cas pour le commit N, ce qui donne l’historique suivant :

	  .-A---M--.
	 /     /    \
	I     B      R
	 \   /      /
	  \ /      /
	   `---X--'

Dans cette optique, nous voyons toutes les modifications monoparentales de A, B et X. Nous voyons également la fusion M, soigneusement résolue, et la fusion R, pas si soigneusement résolue. Ces informations sont généralement suffisantes pour déterminer pourquoi les commits A et B ont « disparu » de l’historique dans la vue par défaut. Cependant, cette approche pose quelques problèmes.

La première question est celle de la performance. Contrairement à toutes les options précédentes, l’option --simplify-merges nécessite de parcourir l’historique complet des commits avant de renvoyer un seul résultat. Cela peut rendre l’option difficile à utiliser pour les très grands dépôts.

La deuxième question est celle de l’audit. Lorsque plusieurs contributeurs travaillent sur le même dépôt, il est important de savoir quels commits de fusion ont introduit un changement dans une branche importante. La fusion problématique R ci-dessus n’est probablement pas le commit de fusion qui a été utilisé pour fusionner dans une branche importante. Au lieu de cela, la fusion N a été utilisée pour fusionner R et X dans la branche importante. Ce commit peut avoir des informations sur la raison pour laquelle la modifcation X est venu remplacer les changements de A et B dans son message de commit.

--show-pulls

En plus des commits indiqués dans l’historique par défaut, montrer chaque commit de fusion qui n’est pas MEMEARBRE à son premier parent, mais qui est MEMEARBRE à un parent ultérieur.

Quand un commit de fusion est inclus par --show-pulls, cette fusion est traitée comme si elle avait "tiré" le changement d’une autre branche. Lorsque l’on utilise --show-pulls sur cet exemple (et aucune autre option), le graphe résultant est :

	I---X---R---N

Ici, les commits de fusion R 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).

Assistants de bissection

--bisect

Limiter la sortie à l’objet commit qui est à peu près à mi-chemin entre les commits inclus et les commits exclus. Notez que la référence mauvaise de bissection refs/bisect/bad est ajoutée aux commits inclus (si elle existe) et la référence bonne de bissection refs/bisect/good-* est ajoutée aux commits exclus (s’ils existent). Ainsi, en supposant qu’il n’y ait pas de références dans refs/bisect/, si

	$ git rev-list --bisect foo ^bar ^baz

affiche midpoint, la sortie des deux commandes

	$ git rev-list foo ^midpoint
	$ git rev-list midpoint ^bar ^baz

seraient à peu près de la même longueur. Trouver le changement qui introduit une régression se réduit donc à une recherche binaire : générer et tester à plusieurs reprises de nouveaux midpoint jusqu’à ce que la chaîne de commits soit de longueur un.

--bisect-vars

Cela calcule la même chose que --bisect, sauf que les références dans refs/bisect/ ne sont pas utilisées, et sauf que cela affiche un texte prêt à être évalué par le shell. Ces lignes attribueront le nom de la révision à mi-parcours à la variable bisect_rev, et le nombre prévu de commits à tester après bisect_rev est testé à bisect_nr, le nombre prévu de commits à tester si bisect_rev s’avère être bon à bisect_good, le nombre prévu d’engagements à tester si bisect_rev s’avère être mauvais à bisect_bad, et le nombre de commits que nous sommes en train de bissecter en ce moment à bisect_all.

--bisect-all

Ceci affiche tous les objets commit entre les commits inclus et exclus, classés selon leur distance par rapport aux commits inclus et exclus. Les références dans refs/bisect/ ne sont pas utilisées. Le plus éloigné d’eux est affiché en premier. (C’est le seul affiché par --bisect.)

Ceci est utile car il est facile de choisir un bon commit à tester lorsque vous voulez éviter de tester certains d’entre eux pour une raison quelconque (ils peuvent ne pas compiler par exemple).

Cette option peut être utilisée avec ‘--bisect-vars’, dans ce cas, après tous les objets commit triés, le texte sera le même que si ‘--bisect-vars’ avait été utilisé seul.

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.

--objects

Imprimer les ID d’objet de tout objet référencé par les commits listés. --objects foo ^bar signifie donc “envoie-moi tous les ID d’objets que je dois télécharger si j’ai l’objet commit bar mais pas foo”. Voir aussi --object-names ci-dessous.

--in-commit-order

Imprimer les identifiants des arbres et des blobs dans l’ordre des commits. Les identifiants des arbres et des blobs sont imprimés que lors qu’ils sont référencés la première fois par un commit.

--objects-edge

Semblable à --objects, mais afficher aussi les ID des commits exclus préfixés par un caractère “-”. Ceci est utilisé par git-pack-objects[1] pour construire un paquet “thin”, qui enregistre les objets sous forme déltaifiée en fonction des objets contenus dans ces commits exclus pour réduire le trafic réseau.

--objects-edge-aggressive

Similaire à ‘--objects-edge’, mais s’efforce de trouver les commits exclus au prix d’un temps plus long de traitement. Ceci est utilisé à la place de ‘--objects-edge’ pour construire des paquets “thin” pour les dépôts superficiels.

--indexed-objects

Faire comme si tous les arbres et tous les blobs utilisés par l’index étaient listés sur la ligne de commande. Notez que vous voudrez probablement utiliser aussi --objects.

--unpacked

Uniquement utile avec --objects ; afficher les ID d’objets qui ne sont pas dans les paquets.

--object-names

Uniquement utile avec --objects ; affiche les noms des IDs d’objets trouvés. C’est le comportement par défaut. Notez que le "nom" de chaque objet est ambigu, et qu’il est principalement destiné à servir d’indice pour l’empaquetage des objets. En particulier : aucune distinction n’est faite entre les noms des étiquettes, des arbres et des blobs ; les noms des chemins peuvent être modifiés pour supprimer les nouvelles lignes ; et si un objet apparaît plusieurs fois avec des noms différents, un seul nom est affiché.

--no-object-names

Uniquement utile avec --objects ; ne pas afficher les noms des ID des objets trouvés. Ceci inverse --object-names. Ce drapeau permet à la sortie d’être plus facilement analysée par des commandes telles que git-cat-file[1].

--filter=<spéc. du filtre>

Uniquement utile avec l’un des ‘--objects* ; omettre des objets (généralement les blobs) de la liste des objets affichés. Le<spécificateur-de-filtre>’ peut être l’un des suivants :

La forme --filter=blob:none omet tous les blobs.

La forme'--filter=blob:limit=<n>[kmg]' omet les blobs d’au moins n octets ou unités. n peut être zéro. Les suffixes k, m et g peuvent être utilisés pour nommer les unités en Kio, Mio ou Gio. Par exemple,blob:limit=1k est identique à blob:limit=1024.

La forme --filter=object:type=(tag|commit|tree|blob) permet d’omettre tous les objets qui ne sont pas du type demandé.

La forme --filter=sparse:oid=<blob-esque> utilise une spécification d’extraction clairsemée contenue dans le blob (ou l’expression de blob) <blob-esque> pour omettre les blobs qui ne seraient pas nécessaires pour une extraction clairsemée sur les références demandées.

La forme --filter=tree:<profondeur> omet tous les blobs et tous les arbres dont la profondeur de l’arbre racine est >= <profondeur> (profondeur minimale si un objet est situé à plusieurs profondeurs dans les commits traversés). <profondeur>=0 n’inclura pas d’arbres ni de blobs à moins d’être inclus explicitement dans la ligne de commande (ou dans l’entrée standard lorsque --stdin est utilisé). <profondeur>=1 inclura seulement l’arbre et les blobs qui sont référencés directement par un commit accessible depuis <commit> ou un objet explicitement donné. <profondeur>=2 est comme <profondeur>=1 tout en incluant aussi les arbres et les blobs d’un niveau supplémentaire tiré d’un commit ou d’un arbre explicitement donné.

Notez que la forme --filter=sparse:path=<chemin> qui veut lire à partir d’un chemin arbitraire sur le système de fichiers a été supprimé pour des raisons de sécurité.

Plusieurs drapeaux --filter= peuvent être spécifiés pour combiner les filtres. Seuls les objets acceptés par tous les filtres sont inclus.

La forme'--filter=combine:<filtre1>+<filtre2>+…​<filtreN>' peut aussi être utilisée pour combiner plusieurs filtres, mais c’est plus difficile que de répéter simplement le drapeau'--filter' et ce n’est généralement pas nécessaire. Les filtres sont joints par des signes + et les filtres individuels sont codés en % (c’est-à-dire codés comme des URL). Outre les caractères + et'%', les caractères suivants sont réservés et doivent également être encodés : ~!@#$^^&*()[]{]{}\ ;",<>?'` ainsi que tous les caractères avec un code ASCII ⇐ 0x20, qui inclut l’espace et la ligne nouvelle.

D’autres caractères arbitraires peuvent également être encodés. Par exemple,combine:tree:3+blob:none et combine:tree%3A3+blob%3Anone sont équivalents.

--no-filter

Désactiver tout argument --filter= précédent.

--filter-provided-objects

Filtrer la liste des objets explicitement fournis, qui autrement seraient toujours imprimés même s’ils ne correspondent à aucun des filtres. Seulement utile avec --filter=.

--filter-print-omitted

Uniquement utile avec --filter= ; imprimer une liste des objets omis par le filtre. Les ID d’objet sont préfixés par un caractère "~".

--missing=<action-manquante>

Une option de débogage pour aider au développement futur de "clones partiels". Cette option spécifie comment les objets manquants sont traités.

La forme --missing=error demande que rev-list s’arrête avec une erreur si un objet manquant est rencontré. C’est l’action par défaut.

La forme --missing=allow-any permet de continuer le parcours d’objet si un objet manquant est rencontré. Les objets manquants seront silencieusement omis des résultats.

Le forme --missing=allow-promisor est comme allow-any, mais ne permettra la traversée d’objets de continuer que pour les objets manquants du promettant EXPECTED. Les objets manquants inattendus entraîneront une erreur.

La forme --missing=print est comme allow-any, mais affichera aussi une liste des objets manquants. Les ID d’objet sont préfixés par un caractère "?".

--exclude-promisor-objects

(Pour usage interne seulement.) Préfiltrer la traversée de l’objet à la limite du promettant. Ceci est utilisé avec un clone partiel. C’est plus fort que --missing=allow-promisor parce qu’il limite la traversée, plutôt que de simplement réduire au silence les erreurs sur les objets manquants.

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

En utilisant ces options, git-rev-list[1] agira de la même manière que la famille plus spécialisée d’outils de journaux de validation : git-log[1], git-show[1] et git-whatchanged[1]

--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 un préfixe qui nomme l’objet de manière unique. L’option "--abbrev=<n>" (qui modifie également la sortie diff, si elle est affichée) peut être utilisée pour spécifier la longueur minimale du préfixe.

Cela devrait rendre "--pretty=oneline" 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, qu’elle soit explicitement ou implicitement impliquée par d’autres options telles que "--oneline". Elle remplace également la variable log.abbrevCommit.

--oneline

C’est un raccourci pour "--pretty=oneline --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. De même, si iconv(3) ne parvient pas à convertir le commit, nous produirons tranquillement l’objet original tel quel.

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

--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 %s, %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 basé sur la sortie de ctime(3). Il affiche une seule ligne avec le jour de la semaine à trois lettres, le mois à trois lettres, le jour du mois, l’heure, la minute et la seconde au format "HH:MM:SS", suivi de l’année à 4 chiffres, plus les informations du fuseau horaire, à moins que le fuseau horaire local ne soit utilisé, par exemple Thu Jan 1 00:00:00 1970 +0000.

--header

Afficher le contenu du commit en format brut ; chaque enregistrement est séparé par un caractère NUL.

--no-commit-header

Supprime la ligne d’en-tête contenant "commit" et l’ID de l’objet affiché avant le format spécifié. Ceci n’a aucun effet sur les formats intégrés ; seuls les formats personnalisés sont concernés.

--commit-header

Remplacer un --no-commit-header précédent.

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

--timestamp

Imprimer l’horodatage brut du commit.

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

--count

Imprimer un nombre indiquant combien de commits auraient été listés, et supprimer toutes les autres sorties. Lorsqu’il est utilisé avec --left-right, imprimer à la place les comptes des commits gauche et droite, séparés par une tabulation. Lorsqu’utilisé avec --cherry-mark, omettre les commits équivalents de rustines de ces comptes et imprimer le compte des commits équivalents séparés par une tabulation.

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>, <date-d'auteur-courte>)

    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-de-formatage>

    Le format format:<chaîne-de-formatage> 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

      %x suivi de deux chiffres hexadécimaux est remplacé par un octet avec la valeur des chiffres hexadécimaux (nous appellerons ceci "code de formatage littéral" dans le reste du document).

    • 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(…​)

      spécification de couleur, telle que décrite sous Valeurs dans la 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 de rebouclage de ligne, comme l’option -w de git-shortlog[1].

      %<( <N> [,trunc|ltrunc|mtrunc])

      faire en sorte que l’espace réservé suivant prenne au moins N largeurs de colonne, en remplissant les espaces à droite si nécessaire. Tronquer éventuellement (avec points de suspension ..) à gauche (ltrunc) .. che, le milieu (mtrunc) mi.. eu, ou la droite (trunc) 'dr.. ', si la sortie est plus longue que N colonnes. Note 1 : cette troncation ne fonctionne correctement qu’avec N >= 2. Note 2 : les espaces autour des valeurs N et M (voir ci-dessous) sont facultatifs. Remarque 3 : Les emojis et autres caractères larges prendront deux colonnes d’affichage, ce qui peut dépasser les limites des colonnes. Note 4 : les marques de combinaison de caractères décomposés peuvent être mal placées au niveau des limites de rembourrage.

      %<|( <M> )

      faire en sorte que l’espace réservé suivant prenne au moins jusqu’à la Mième colonne d’affichage, en remplissant les espaces sur la droite si nécessaire. Utilisez des valeurs M négatives pour les positions de colonne mesurées à partir du bord droit de la fenêtre du terminal.

      %>( <N> ), %>|( <M> )

      similaire à %<( <N> ), %<|( <M> ) respectivement, mais les espaces d’alignement à gauche

      %>>( <N> ), %>>|( <M> )

      similaire à %>( <N> ), %>|( <M> ) 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> ), %><|( <M> )

      similaire à %<( <N> ), %<|( <M> ) respectivement, mais en dé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 .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)

      %ah

      date de l’auteur, style humain (comme l’option --date=human de git-rev-list[1])

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

      %ch

      date du validateur, style humain (comme l’option --date=human de git-rev-list[1])

      %d

      les noms de ref, comme l’option --decorate de git-log[1].

      %D

      les noms des refs, sans encadrement par « ( » et « ) ».

      %(decorate[:<options>])

      noms de réfs avec des décorations personnalisées. La chaîne "decorate" peut être suivie de deux points et de zéro ou plus options séparées par des virgules. Les valeurs d’option peuvent contenir des codes de formatage litéraux. Ils doivent être utilisés pour les virgules (%x2C) et les parenthèses de fermeture (%x29), en raison de leur rôle dans la syntaxe optionnelle.

      • prefix=<valeur> : Affiché avant la liste des noms de réf. Valeur pas défaut " (".

      • suffix= <valeur> : affiché après la liste des noms réf. Valeur par défaut à ")".

      • separator=<valeur> : affiché entre les noms de réf. Valeur par défaut à ",  ".

      • pointer=<valeur> : Affichage entre HEAD et la branche pointée, le cas échéant. Par défaut " -> ".

      • tag= <valeur> : Afficher avant les noms des étiquettes. par défaut "tag: ".

    Par exemple, pour produire des décorations sans enveloppe ni étiquettes, et des espaces comme séparateurs :

    + %(decorate:prefix=,suffix=,tag=,separator= )

    %(describe[:<options>])

    nom lisible par l’homme, comme git-describe[1] ; chaîne vide pour les commits non descriptibles. La chaîne describe peut être suivie de deux points et de zéro ou plusieurs options séparées par des virgules. Les descriptions peuvent être incohérentes lorsque des étiquettes sont ajoutées ou supprimées en même temps.

    • tags[=<valeur-booléenne>] : Au lieu de ne considérer que les étiquettes annotées, prendre également en compte les étiquettes légères.

    • abbrev=<nombre> : Au lieu d’utiliser le nombre de chiffres hexadécimaux par défaut (qui varie en fonction du nombre d’objets dans le dépôt avec une valeur par défaut de 7) du nom d’objet abrégé, utiliser <nombre> chiffres, ou autant de chiffres que nécessaire pour former un nom unique.

    • match=<motif> : Ne considère que les étiquettes correspondant au motif glob(7) donné, à l’exclusion du préfixe "refs/tags/".

    • exclude=<motif>' : Ne pas prendre en compte les étiquettes correspondant au motif glob(7) donné, en excluant le préfixe "refs/tags/".

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

    %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, p. ex., 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 nom de la référence 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 refname est raccourcie pour la lisibilité humaine (ainsi refs/heads/master devient simplement master).

    %gn

    nom de l’identité reflog

    %gN

    nom de l’identité reflog (en respectant .mailmap, voir git-shortlog[1] ou git-blame[1])

    %ge

    adresse de courriel d’identité reflog

    %gE

    e-mail de l’identité reflog (en respectant .mailmap, voir git-shortlog[1] ou git-blame[1])

    %gs

    titre du reflog

    %(trailers[:<options>])

    afficher les lignes ajoutées du corps comme interprétées 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. Si une option est fournie plusieurs fois, la dernière option l’emporte.

    • key=<clé>' : 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 [=<BOOLÉEN>]' : choisir si les lignes non annotées du bloc de lignes finales doivent être incluses.

    • 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. 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[=<booléen>] : se comporter comme si l’option --unfold d’interprétation des attributs était donnée. Par exemple, %(trailers:only,unfold=true) déplie et affiche toutes les lignes d’attributs.

    • keyonly [=<booléen>] : ne montrer que la partie principale du bloc final.

    • valueonly [=<booléen>] : n’affichez que la partie valeur des lignes finales.

    • key_value_separator=<sep> : spécifier un séparateur inséré entre les lignes finales. Si cette option n’est pas fournie, chaque paire clé-valeur de la ligne finale est séparée par " :", sinon elle partage la même sémantique que separator=<sep> ci-dessus.

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.

Les options booléennes acceptent une valeur optionnelle [=<booléen>]. Les valeurs true, false, on, off etc. sont toutes acceptées. Voir la sous-section "booléen" dans "EXEMPLES" dans git-config[1]. Si une option booléenne est donnée sans valeur, elle est activée.

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

GIT

Fait partie de la suite git[1]

TRADUCTION

Cette page de manuel a été traduite par Jean-Noël Avila <jn.avila AT free DOT fr> et les membres du projet git-manpages-l10n. Veuillez signaler toute erreur de traduction par un rapport de bogue sur le site https://github.com/jnavila/git-manpages-l10n .

scroll-to-top