Git 🌙
Français ▾ Topics ▾ Latest version ▾ git-rev-list last updated in 2.45.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 un 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

Afficher les commits touchant les chemins conflictuels dans la plage HEAD... <autre>, oĂą <autre> est la première pseudo-ref existante dans MERGE_HEAD, CHERRY_PICK_HEAD, REVERT_HEAD ou REBASE_HEAD. Fonctionne seulement lorsque l’index a des entrĂ©es non fusionnĂ©es. Cette option peut ĂŞtre utilisĂ©e pour montrer les commits pertinents lors de la rĂ©solution des conflits Ă  partir d’une fusion Ă  3 voies.

--boundary

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

--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 de commits Ă  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 "?".

Si quelques sommets passés à la traversée sont manquants, ils seront considérés comme manquants aussi, et la traversée les ignorera. Dans le cas où nous ne pouvons pas obtenir leur ID Objet, une erreur sera soulevée.

--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 le sĂ©parateur insĂ©rĂ© entre les lignes d’attributs. Par dĂ©faut, 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 le sĂ©parateur insĂ©rĂ© entre la clĂ© et la valeur dans chaque ligne terminale. Par dĂ©faut " :". 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