Setup and Config
Getting and Creating Projects
Basic Snapshotting
Branching and Merging
Sharing and Updating Projects
Inspection and Comparison
Patching
Debugging
External Systems
Server Admin
Guides
- gitattributes
- Command-line interface conventions
- Everyday Git
- Frequently Asked Questions (FAQ)
- Glossary
- Hooks
- gitignore
- gitmodules
- Revisions
- Submodules
- Tutorial
- Workflows
- All guides...
Administration
Plumbing Commands
- 2.45.1 → 2.47.0 no changes
- 2.45.0 04/29/24
- 2.43.3 → 2.44.2 no changes
- 2.43.2 02/13/24
- 2.43.1 no changes
- 2.43.0 11/20/23
- 2.42.1 → 2.42.3 no changes
- 2.42.0 08/21/23
- 2.41.1 → 2.41.2 no changes
- 2.41.0 06/01/23
- 2.40.1 → 2.40.3 no changes
- 2.40.0 03/12/23
- 2.39.1 → 2.39.5 no changes
- 2.39.0 12/12/22
- 2.38.1 → 2.38.5 no changes
- 2.38.0 10/02/22
- 2.37.1 → 2.37.7 no changes
- 2.37.0 06/27/22
- 2.36.1 → 2.36.6 no changes
- 2.36.0 04/18/22
- 2.35.1 → 2.35.8 no changes
- 2.35.0 01/24/22
- 2.33.3 → 2.34.8 no changes
- 2.33.2 03/23/22
- 2.33.1 10/12/21
- 2.33.0 08/16/21
- 2.32.1 → 2.32.7 no changes
- 2.32.0 06/06/21
- 2.31.1 → 2.31.8 no changes
- 2.31.0 03/15/21
- 2.30.1 → 2.30.9 no changes
- 2.30.0 12/27/20
- 2.29.1 → 2.29.3 no changes
- 2.29.0 10/19/20
- 2.28.1 no changes
- 2.28.0 07/27/20
- 2.27.1 no changes
- 2.27.0 06/01/20
- 2.26.1 → 2.26.3 no changes
- 2.26.0 03/22/20
- 2.25.1 → 2.25.5 no changes
- 2.25.0 01/13/20
- 2.24.1 → 2.24.4 no changes
- 2.24.0 11/04/19
- 2.23.1 → 2.23.4 no changes
- 2.23.0 08/16/19
- 2.22.1 → 2.22.5 no changes
- 2.22.0 06/07/19
- 2.21.1 → 2.21.4 no changes
- 2.21.0 02/24/19
- 2.20.1 → 2.20.5 no changes
- 2.20.0 12/09/18
- 2.19.3 → 2.19.6 no changes
- 2.19.2 11/21/18
- 2.17.1 → 2.19.1 no changes
- 2.17.0 04/02/18
- 2.16.6 12/06/19
- 2.15.4 12/06/19
- 2.14.6 12/06/19
- 2.13.7 05/22/18
- 2.12.5 09/22/17
- 2.11.4 09/22/17
- 2.10.5 09/22/17
- 2.9.5 07/30/17
- 2.8.6 07/30/17
- 2.7.6 07/30/17
- 2.6.7 05/05/17
- 2.5.6 05/05/17
- 2.4.12 05/05/17
- 2.3.10 09/28/15
- 2.2.3 09/04/15
- 2.1.4 12/17/14
- 2.0.5 12/17/14
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 queHEAD
, étaient listées sur la ligne de commande comme'<commit>'. - --branches[=<motif>]
-
Faire comme si toutes les refs de
refs/heads
étaient listées sur la ligne de commande comme'<commit>'. Si'<motif>' est fournir, limiter les branches à celles qui correspondent à un glob shell donné. Si le motif ne présente pas de ?, *, ni [, /* à la fin est implicite. - --tags[=<motif>]
-
Faire comme si toutes les refs de
refs/tags
étaient listées sur la ligne de commande comme'<commit>'. Si'<motif>' est fournir, limiter les étiquettes à celles qui correspondent à un glob shell donné. Si le motif ne présente pas de ?, *, ni [, /* à la fin est implicite. - --remotes[=<motif>]
-
Faire comme si toutes les refs de ‘refs/remotes’ Ă©taient listĂ©es sur la ligne de commande comme'<commit>'. Si'<motif>' est donnĂ©, limiter les branches de suivi Ă distance Ă celles qui correspondent Ă un glob shell donnĂ©. Si le motif ne prĂ©sent pas ?, *, ni [, /* Ă la fin est implicite.
- --glob=<motif-glob>
-
Faire comme si toutes les rĂ©fs correspondant au shell glob'<motif-glob>' Ă©taient listĂ©es sur la ligne de commande comme'<commit>'. Le prĂ©fixe refs/, est automatiquement ajoutĂ© s’il n’y en a pas. Si le motif ne prĂ©sente pas de ?, *, ni [, /* Ă la fin est implicite.
- --exclude=<motif-glob>
-
Ne pas inclure les références correspondant à '<glob-pattern>' que les
--all
,--branches
,--tags
,--remotes
, ou--glob
suivantes considĂ©reraient autrement. Les rĂ©pĂ©titions de cette option accumulent les motifs d’exclusion jusqu’Ă la prochaine option--all
,--branches
,--tags
,--remotes
ou--glob
(les autres options ou arguments n’Ă©liminent pas les motifs accumulĂ©s).Les motifs donnĂ©s ne doivent pas commencer par
refs/heads
,refs/tags
, ourefs/remotes
lorsqu’ils sont appliquĂ©s Ă--branches
,--tags
, ou--remotes
, respectivement, et ils doivent commencer parrefs/
lorsqu’ils sont appliquĂ©s Ă--glob
ou--all
. Si un'/*' final est intentionnel, il doit être donné explicitement. -
Ne pas inclure les références qui seraient cachées par
git-fetch
,git-receive-pack
ougit-upload-pack
en consultant la configurationfetch.hideRefs
,receive.hideRefs
ouuploadpack.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Ă© parcore.alternateRefsCommand
, etc. Voir git-config[1]. - --single-worktree
-
Par dĂ©faut, tous les arbres de travail seront examinĂ©s par les options suivantes lorsqu’il y en a plusieurs (voir git-worktree[1]) :
--all
,--reflog
et--indexed-objects
. Cette option les oblige Ă n’examiner que l’arbre de travail actuel. - --ignore-missing
-
En voyant un nom d’objet invalide dans l’entrĂ©e, faire comme si la mauvaise entrĂ©e n’avait pas Ă©tĂ© donnĂ©e.
- --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 sectionAVERTISSEMENTS
dans git-cat-file[1] pour les limitations de ce que signifie "stockage sur disque". Avec la valeur optionnellehuman
, 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
etB
, une façon habituelle de lister tous les commits d’un seul cĂ´tĂ© d’entre elles est avec--left-right
(voir l’exemple ci-dessous dans la description de l’option--left-right
). Cependant, cela montre les commits qui ont Ă©tĂ© picorĂ©s sur l’autre branche (par exemple, “3rd on b” peut ĂŞtre triĂ© sur la branche A). Avec cette option, ces paires de commits sont exclues de la sortie. - --left-only
- --right-only
-
Ne lister que les commits du cĂ´tĂ© respectif d’une diffĂ©rence symĂ©trique, c’est-Ă -dire seulement ceux qui seraient marquĂ©s
<
resp.>
par--left-right
.Par exemple,
--cherry-pick --right-only A...B
omet les commits deB
qui sont dansA
ou sont Ă©quivalents en rustine Ă un commit enA
. En d’autres termes, cela liste les commits+
degit cherry A B
. Plus précisément,--cherry-pick --right-only --no-merges
donne la liste exacte. - --cherry
-
Un synonyme pour
--right-only --cherry-mark --no-merges
; utile pour limiter la sortie aux commits de notre cĂ´tĂ© et marquer ceux qui ont Ă©tĂ© appliquĂ©s de l’autre cĂ´tĂ© d’un historique en fourche avecgit log --cherry amont...mabranche', similaire Ă `git cherry upstream mabranche
. - -g
- --walk-reflogs
-
Au lieu de marcher dans la chaĂ®ne des commits ancĂŞtres, parcourir les entrĂ©es de reflog du plus rĂ©cent au plus ancien. Lorsque cette option est utilisĂ©e, vous ne pouvez pas spĂ©cifier de commits Ă exclure (c’est-Ă -dire que les notations ^commit, commit1..commit2 et’commit1...commit2' ne peuvent pas ĂŞtre utilisĂ©es).
Avec un format
--pretty
autre queonline
etreference
(pour des raisons Ă©videntes), cela fait que la sortie a deux lignes supplĂ©mentaires d’informations tirĂ©es du reflog. L’indicateur de reflog dans la sortie peut ĂŞtre affichĂ© commeref@{<Nième>}
(oĂą <Nième> est l’index chronologique inverse dans le reflog) ou commeref@{<horodatage>}
(avec l'<horodatage> pour cette entrée), selon quelques règles :-
Si le point de départ est spécifié comme
ref@{<Nième>}
, afficher le format de l’index. -
Si le point de départ a été spécifié comme
ref@{now}
, afficher le format de l’horodatage. -
Si ni l’un ni l’autre n’a Ă©tĂ© utilisĂ©, mais que
--date' a été donné sur la ligne de commande, afficher l'horodatage dans le format demandé par `--date
. -
Sinon, afficher le format de l’index.
Sous
--pretty=oneline
, le message de commit est préfixé avec cette information sur la même ligne. Cette option ne peut pas être combinée avec--reverse
. Voir aussi git-reflog[1].Sous l’option
--pretty=reference
, ces informations ne seront pas affichées du tout. -
- --merge
-
Afficher les commits touchant les chemins conflictuels dans la plage
HEAD... <autre>
, oĂą<autre>
est la première pseudo-ref existante dansMERGE_HEAD
,CHERRY_PICK_HEAD
,REVERT_HEAD
ouREBASE_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 :
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 fichierquux
existe avec le contenu 'quux'. Les commits initiaux sont comparés à un arbre vide, doncI
est !MEMEARBRE. -
Dans
A
,foo
ne contient que “foo”. -
B
contient le mĂŞme changement queA
. Sa fusionM
est triviale et donc MEMEARBRE pour tous les parents. -
C
ne change pasfoo
, mais sa fusionN
le change en “foobar”, donc ce n’est pas MEMEARBRE Ă aucun parent. -
D
metfoo
surbaz
. Sa fusionO
combine les chaînes de caractères deN
etD
Ă “foobarbaz” ; c’est-Ă -dire qu’elle n’est pas MEMEARBRE Ă aucun parent. -
E
changequux
en “xyzzy”, et sa fusionP
combine les chaĂ®nes en “quux xyzzy”.P
est MEMEARBRE ĂO
, mais pas ĂE
. -
X
est un commit racine indépendant qui a ajouté un nouveau fichierside
, etY
l’a modifiĂ©.Y
est MEMEARBRE ĂX
. Sa fusionQ
a ajoutéside
ĂP
, etQ
est MEMEARBRE ĂP
, mais pas ĂY
.
rev-list
traverse en arrière l’historique, y compris ou en excluant les commits en fonction de si --full-history
et / ou la rĂ©Ă©criture des parents (par l’intermĂ©diaire de --parents
ou --children
) sont utilisés. Les paramètres suivants sont disponibles.
- Mode par défaut
-
Les commits sont inclus s’ils ne sont pas MEMEARBRE Ă un parent (bien que ceci puisse ĂŞtre changĂ©, voir
--sparse
ci-dessous). Si le commit Ă©tait une fusion, et que c’Ă©tait MEMEARBRE Ă un des parents, ne suivez que ce parent. (MĂŞme s’il y a plusieurs parents MEMEARBRE, ne suivez qu’un seul d’entre eux.) Sinon, suivez tous les parents.Il en rĂ©sulte :
.-A---N---O / / / I---------D
Notez que la règle de ne suivre que le parent MEMEARBRE, s’il y en a un disponible, a entièrement supprimĂ©
B
de la considération.C
a été pris en compte viaN
, mais il est MEMEARBRE. Les commits racines sont comparés à un arbre vide, doncI
est !MEMEARBRE.Les relations parents/enfants ne sont visibles qu’avec
--parents
, mais cela n’affecte pas les commits sĂ©lectionnĂ©s en mode par dĂ©faut, nous avons donc montrĂ© les lignes parentales. - --full-history sans rĂ©Ă©criture des parents
-
Ce mode diffère du mode par dĂ©faut en un point : toujours suivre tous les parents d’une fusion, mĂŞme si c’est MEMEARBRE Ă l’un d’eux. MĂŞme si plus d’un cĂ´tĂ© de la fusion a des commits qui sont inclus, cela ne signifie pas que la fusion elle-mĂŞme l’est ! Dans l’exemple, nous obtenons
I A B N D O P Q
M
a Ă©tĂ© exclu parce qu’il s’agit d’un MEMEARBRE pour les deux parents.E
,C
etB
ont tous été parcourus, mais seulB
Ă©tait un !MEMEARBRE, donc les autres n’apparaissent pas.Notez que sans rĂ©Ă©criture des parents, il n’est pas vraiment possible de parler des relations parent/enfant entre les commits, donc nous les montrons dĂ©connectĂ©s.
- --full-history 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 queE
a Ă©tĂ© Ă©laguĂ© parce que c’est MEMEARBRE, mais la liste parent de P a Ă©tĂ© rĂ©Ă©crite pour contenir le parentI
deE
. Il en a été de même pourC
etN
, etX
,Y
etQ
.
En plus des paramètres ci-dessus, vous pouvez modifier si MEMEARBRE affecte l’inclusion :
- --dense
-
Les commits qui sont parcourus sont inclus s’ils ne sont pas MEMEARBRE pour aucun parent.
- --sparse
-
Tous les commits qui sont parcourus sont inclus.
Notez que sans
--full-history
, cela simplifie encore les fusions : si l’un des parents est MEMEARBRE, nous ne suivons que celui-lĂ , donc les autres cĂ´tĂ©s de la fusion ne sont jamais parcourus. - --simplify-merges
-
Tout d’abord, construire un graphe d’historique de la mĂŞme manière que
--full-history
avec la réécriture des parents (voir ci-dessus).Puis simplifier chaque commit
C
Ă son remplacementC'
dans l’historique final selon les règles suivantes :-
DĂ©finir
C'
surC
. -
Remplacer chaque parent
P
deC'
par sa simplificationP'
. Dans le processus, dĂ©poser les parents qui sont les ancĂŞtres d’autres parents ou qui sont des commits racines MEMEARBRE Ă un arbre vide, et supprimer les doublons, mais prendre soin de ne jamais laisser tomber tous les parents auxquels nous sommes MEMEARBRE. -
Si après cette réécriture des parents,
C'
est un commit racine ou de fusion (qui a zéro ou >1 parents), un commit limite, ou !MEMEARBRE, il est conservé. Sinon, il est remplacé par son seul parent.
L’effet de ceci est mieux montrĂ© en comparant avec
--full-history
avec la rĂ©Ă©criture des parents. L’exemple se transforme en :.-A---M---N---O / / / I B D \ / / `---------'
Notez les principales différences entre
N
,P
etQ
par rapport Ă--full-history
:-
'La liste des parents de
N
a Ă©tĂ© supprimĂ©e, parce qu’elle est un ancĂŞtre de l’autre parentM
. Pourtant,N
est restĂ© parce qu’il est !MEMEARBRE. -
De mĂŞme, la liste des parents de
P
a euI
supprimé.P
a ensuite Ă©tĂ© complètement enlevĂ©, parce qu’il avait un parent et qu’il est MEMEARBRE. -
La liste des parents de
Q
a renduY
simplifié enX
.X
a ensuite Ă©tĂ© supprimĂ©, parce que c’Ă©tait une racine MEMEARBRE.Q
a ensuite Ă©tĂ© complètement supprimĂ©e, parce qu’elle avait un parent et qu’il est MEMEARBRE.
-
Il existe un autre mode de simplification :
- --ancestry-path[=<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 deD
. C’est utile pour voir ce qui s’est passĂ© dans l’historique qui a menĂ© ĂM
depuis leD
, au sens de « ce queM
a qui n’existait pas dansD
 ». Le résultat dans cet exemple serait tous les commits, saufA
etB
(etD
lui-même, bien sûr).Quand nous voulons savoir quels commits dans
M
sont contaminés par le bogue introduit parD
et ont besoin d’ĂŞtre corrigĂ©s, cependant, nous pourrions vouloir voir seulement le sous-ensemble de D..M qui sont en fait des descendants deD
, c’est-Ă -dire en excluantC
etK
. C’est exactement ce que fait l’option--ancestry-path
. AppliquĂ© Ă l’intervalle D..M, il se traduit en :E-------F \ \ G---H---I---J \ L--M
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ésultatK---------------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
etN
sont inclus, car ils ont tiré les commitsX
etR
dans la branche de base, respectivement. Ces fusions sont les raisons pour lesquelles les commitsA
etB
n’apparaissent pas dans l’historique par dĂ©faut.Lorsque l’option
--show-pulls
est associĂ©e Ă l’option--simplify-merges
, le graphe comprend toutes les informations nécessaires :.-A---M--. N / / \ / I B R \ / / \ / / `---X--'
Remarquez que puisque
M
est accessible Ă partir deR
, l’arĂŞte entreN
etM
a été simplifiée. Cependant,N
apparaĂ®t toujours dans l’historique comme un commit important parce qu’il a « tiré » le changementR
dans la branche principale.
L’option --simplify-by-decoration
vous donne une vue d’ensemble de la topologie de l’historique, en omettant les commits qui ne sont pas rĂ©fĂ©rencĂ©s par des Ă©tiquettes. Les commits sont marquĂ©s comme !MEMEARBRE(en d’autres termes, conservĂ©s après les règles de simplification de l’historique dĂ©crites ci-dessus) si (1) ils sont rĂ©fĂ©rencĂ©s par des Ă©tiquettes, ou (2) ils changent le contenu des chemins donnĂ©s sur la ligne de commande. Tous les autres commits sont marquĂ©s comme MEMEARBRE (soumis Ă une possible simplification).
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 bissectionrefs/bisect/good-*
est ajoutĂ©e aux commits exclus (s’ils existent). Ainsi, en supposant qu’il n’y ait pas de rĂ©fĂ©rences dansrefs/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 dansrefs/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 variablebisect_rev
, et le nombre prévu de commits à tester aprèsbisect_rev
est testĂ© Ăbisect_nr
, le nombre prévu de commits à tester sibisect_rev
s’avère ĂŞtre bon Ăbisect_good
, le nombre prévu de commits à tester sibisect_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 (sisorted
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 variablelog.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 enX
, 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 configlog.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 formatAAA-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Ă© avecstrftime("%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...
versstrftime
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 destrftime
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 exempleThu 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 toutformat:
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 :
-
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ètresauto
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’avecgit 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}
ourefs/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 (doncgit log -g refs/heads/master
produiraitrefs/heads/master@{0}
). - %gd
-
sĂ©lecteur de reflog raccourci ; identique Ă
%gD
, mais la partie refname est raccourcie pour la lisibilité humaine (ainsirefs/heads/master
devient simplementmaster
). - %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Ă© aveconly=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 avaittformat:
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 .