Il s'agit de la commande git-log qui peut être exécutée dans le fournisseur d'hébergement gratuit OnWorks en utilisant l'un de nos multiples postes de travail en ligne gratuits tels que Ubuntu Online, Fedora Online, l'émulateur en ligne Windows ou l'émulateur en ligne MAC OS
PROGRAMME:
Nom
git-log - Afficher les journaux de validation
SYNOPSIS
jet enregistrer [ ] [ ] [[--] ...]
DESCRIPTION
Affiche les journaux de validation.
La commande prend les options applicables à la commande git rev-list pour contrôler ce qui est affiché
et comment, et les options applicables aux commandes git diff-* pour contrôler la façon dont les modifications
les introductions de commit sont affichées.
OPTIONS
--poursuivre
Continuez à lister l'historique d'un fichier au-delà des renommages (ne fonctionne que pour un seul fichier).
--no-decorate, --decorate[=short|full|no]
Imprimez les noms de référence de tous les commits affichés. Si court est spécifié, la réf
préfixes de nom refs/chefs/, références/balises/ et réfs/télécommandes/ ne sera pas imprimé. Si plein
est spécifié, le nom de référence complet (y compris le préfixe) sera imprimé. L'option par défaut
is court.
--la source
Imprimez le nom de référence donné sur la ligne de commande par lequel chaque commit a été atteint.
--use-mailmap
Utilisez le fichier mailmap pour mapper les noms et adresses e-mail des auteurs et des commiteurs à canonique
vrais noms et adresses e-mail. Voir git-shortlog (1).
--full-diff
Sans ce drapeau, git log -p ... affiche les commits qui touchent les chemins spécifiés,
et diffs sur les mêmes chemins spécifiés. Avec cela, le diff complet est affiché pour
commits qui touchent les chemins spécifiés ; cela signifie que " ..." limites seulement
commits, et ne limite pas les différences pour ces commits.
Notez que cela affecte tous les types de sortie basés sur diff, par exemple ceux produits par --stat,
et ainsi de suite
--log-taille
Incluez une ligne « taille du journal " dans la sortie pour chaque commit, où est
la longueur du message de ce commit en octets. Destiné à accélérer les outils qui lisent le journal
messages de la sortie du journal git en leur permettant d'allouer de l'espace à l'avance.
-L , : , -L : :
Trace l'évolution de la gamme de ligne donnée par " , " (ou le nom de la fonction
expression régulière ) dans le . Vous ne pouvez pas donner de limiteurs de pathspec. C'est
actuellement limité à une promenade à partir d'une seule révision, c'est-à-dire que vous ne pouvez donner
zéro ou un argument de révision positif. Vous pouvez spécifier cette option plusieurs fois.
et peut prendre l'une de ces formes :
· numéro
Si ou est un nombre, il spécifie un numéro de ligne absolu (les lignes comptent
à partir de 1).
· /expression régulière/
Ce formulaire utilisera la première ligne correspondant à l'expression régulière POSIX donnée. Si est un
regex, il recherchera à partir de la fin de la plage -L précédente, le cas échéant, sinon
depuis le début du fichier. Si est "^/regex/", il recherchera à partir du début de
déposer. Si est une expression régulière, il recherchera à partir de la ligne donnée par .
· +offset ou -offset
Ceci n'est valable que pour et spécifiera un nombre de lignes avant ou après
la ligne donnée par .
Si ": » est donné à la place de et , c'est une expression régulière
qui dénote la plage de la première ligne funcname qui correspond , jusqu'à la
ligne de nom de fonction suivante. " : ” recherche à partir de la fin de la plage -L précédente, si
any, sinon depuis le début du fichier. « ^ : ” recherche à partir du début du fichier.
Afficher uniquement les commits dans la plage de révisions spécifiée. Quand non est
spécifié, sa valeur par défaut est HEAD (c'est-à-dire tout l'historique menant au commit actuel).
origin..HEAD spécifie tous les commits accessibles depuis le commit courant (ie HEAD),
mais pas d'origine. Pour une liste complète des façons d'épeler , voir le
Spécification Pianos de cuisine l'article de gitrévisions (7).
[--] ...
Afficher uniquement les commits suffisants pour expliquer comment les fichiers qui correspondent au
des chemins se sont créés. Voir Historique Simplification ci-dessous pour plus de détails et autres
modes de simplification.
Les chemins peuvent avoir besoin d'être préfixés par '`-- '' pour les séparer des options ou du
plage de révision, en cas de confusion.
S’ENGAGER Limitation
En plus de spécifier une plage de commits qui doivent être répertoriés en utilisant les notations spéciales
expliqué dans la description, une limitation de commit supplémentaire peut être appliquée.
L'utilisation de plus d'options limite généralement davantage la sortie (par exemple --since= limites à
s'engage plus récent que , et en l'utilisant avec --grep= des limites supplémentaires aux commits
dont le message de journal a une ligne qui correspond ), sauf indication contraire.
Notez que ceux-ci sont appliqués avant les options de commande et de formatage de validation, telles que
--inverser.
- , -n , --max-count=
Limitez le nombre de commits en sortie.
--ignorer=
Skip nombre commits avant de commencer à afficher la sortie de commit.
--depuis= , --après=
Afficher les commits plus récents qu'une date spécifique.
--jusqu'à= , --avant=
Afficher les commits antérieurs à une date spécifique.
--auteur= , --committer=
Limitez la sortie des commits à ceux dont les lignes d'en-tête auteur/committer correspondent au
modèle spécifié (expression régulière). Avec plus d'un --author= , s'engage
dont l'auteur correspond à l'un des modèles donnés sont choisis (de même pour plusieurs
--committer= ).
--grep-reflog=
Limiter la sortie des commits à ceux avec des entrées reflog qui correspondent au modèle spécifié
(expression régulière). Avec plus d'un --grep-reflog, 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 est en cours d'utilisation.
--grep=
Limiter la sortie des commits à ceux avec un message de journal qui correspond au modèle spécifié
(expression régulière). Avec plus d'un --grep= , commits dont le message
correspond à l'un des modèles donnés sont choisis (mais voir --all-match).
Lorsque --show-notes est activé, le message des notes est mis en correspondance comme s'il était
partie du message de journal.
--tout-match
Limitez la sortie des commits à ceux qui correspondent à tous les --grep donnés, au lieu de ceux qui
correspond à au moins un.
--inverser-grep
Limitez la sortie des commits à ceux avec un message de journal qui ne correspond pas au modèle
spécifié avec --grep= .
-i, --regexp-ignore-case
Faites correspondre les modèles de limitation d'expression régulière sans tenir compte de la casse des lettres.
--basic-regexp
Considérez les modèles de limitation comme des expressions régulières de base ; c'est la valeur par défaut.
-E, --expression rationnelle-étendue
Considérez les modèles limitatifs comme des expressions régulières étendues au lieu des
expressions régulières de base par défaut.
-F, --chaînes-fixes
Considérez les modèles limitatifs comme des chaînes fixes (n'interprétez pas le modèle comme un
expression régulière).
--perl-regexp
Considérez les modèles de limitation comme des expressions régulières compatibles Perl. A besoin
libpcre à compiler.
--remove-vide
Arrêtez-vous lorsqu'un chemin donné disparaît de l'arbre.
--fusionne
Imprimer uniquement les commits de fusion. C'est exactement la même chose que --min-parents=2.
--no-fusions
N'imprimez pas les commits avec plus d'un parent. C'est exactement la même chose que
--max-parents=1.
--min-parents= , --max-parents= , --no-min-parents, --no-max-parents
Afficher uniquement les commits qui ont au moins (ou au plus) autant de commits parents. Dans
en particulier, --max-parents=1 est identique à --no-merges, --min-parents=2 est identique à
--fusionne. --max-parents=0 donne tous les commits root et --min-parents=3 tous les octopus
fusionne.
--no-min-parents et --no-max-parents réinitialisent ces limites (à aucune limite).
Les formes équivalentes sont --min-parents=0 (tout commit a 0 ou plusieurs parents) et
--max-parents=-1 (les nombres négatifs n'indiquent aucune limite supérieure).
--premier-parent
Suivez uniquement le premier commit parent lorsque vous voyez un commit de fusion. Cette option peut donner un
meilleure vue d'ensemble lors de la visualisation de l'évolution d'une branche thématique particulière, car
les fusions dans une branche thématique ont tendance à consister uniquement à s'adapter à la mise à jour en amont de
de temps en temps, et cette option vous permet d'ignorer les commits individuels apportés
à votre histoire par une telle fusion. Ne peut pas être combiné avec --bisect.
--ne pas
Inverse le sens de la ^ préfixe (ou son absence) pour toutes les révisions suivantes
spécificateurs, jusqu'au prochain --not.
--tout
Faites comme si toutes les références dans refs/ sont répertoriées sur la ligne de commande comme .
--branches[= ]
Faites comme si toutes les références dans refs/heads étaient répertoriées sur la ligne de commande comme .
If est donné, limitez les branches à celles correspondant au glob du shell donné. Si modèle
manque ?, *, ou [, /* à la fin est implicite.
--tags[= ]
Faites comme si toutes les références dans les références/balises étaient répertoriées sur la ligne de commande comme . Si
est donné, limitez les balises à celles correspondant au glob shell donné. Si le modèle manque ?,
*, ou [, /* à la fin est implicite.
--télécommandes[= ]
Faites comme si toutes les références dans les références/télécommandes étaient répertoriées sur la ligne de commande comme .
If est donné, limitez les branches de suivi à distance à celles correspondant au shell donné
glob. Si le modèle manque ?, *, ou [, /* à la fin est implicite.
--glob=
Faites comme si toutes les références correspondent au shell glob sont répertoriés sur le
ligne de commande comme . Premier réf/, est automatiquement ajouté s'il est manquant. Si
manque de modèle ?, *, ou [, /* à la fin est implicite.
--exclude=
Ne pas inclure les références correspondantes que le prochain --all, --branches, --tags,
--remotes, ou --glob prendrait en compte autrement. Les répétitions de cette option s'accumulent
motifs d'exclusion jusqu'au prochain --all, --branches, --tags, --remotes ou --glob
option (les autres options ou arguments n'effacent pas les motifs accumulés).
Les modèles donnés ne doivent pas commencer par refs/heads, refs/tags ou refs/remotes lorsque
appliqué à --branches, --tags ou --remotes, respectivement, et ils doivent commencer par
refs/ lorsqu'il est appliqué à --glob ou --all. Si une traînée /* est destiné, il doit être donné
explicitement.
--reflog
Faites comme si tous les objets mentionnés par reflogs étaient répertoriés sur la ligne de commande comme
.
--ignore-manquant
En voyant un nom d'objet invalide dans l'entrée, faites comme si la mauvaise entrée n'était pas
donné.
--couper en deux
Faites comme si la mauvaise bissection ref refs/bisect/bad était répertoriée et comme si c'était
suivi de --not et de la bonne bissection refs refs/bisect/good-* sur la ligne de commande.
Ne peut pas être combiné avec --first-parent.
--stdin
En plus de la répertoriés sur la ligne de commande, lisez-les à partir de la norme
saisir. Si un -- séparateur est vu, arrêtez de lire les commits et commencez à lire les chemins vers
limiter le résultat.
--cerise-marque
Comme --cherry-pick (voir ci-dessous) mais marquez les commits équivalents avec = plutôt que d'omettre
eux, et les équivalents avec +.
--cherry-pic
Omettez 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 manière habituelle de lister tous les commits sur
un seul côté d'entre eux est avec --left-right (voir l'exemple ci-dessous dans la description
de l'option --gauche-droite). Cependant, il montre les commits qui ont été triés sur le volet
de l'autre branche (par exemple, « 3e sur b » peut être choisi dans la branche A).
Avec cette option, ces paires de commits sont exclues de la sortie.
--gauche uniquement, --droite uniquement
Lister uniquement les commits du côté respectif d'une plage symétrique, c'est-à-dire uniquement ceux qui
serait marqué < resp. > par --gauche-droite.
Par exemple, --cherry-pick --right-only A...B omet les commits de B qui sont dans
A ou sont l'équivalent d'un patch à un commit dans A. En d'autres termes, cela répertorie les + commits
de git cherry A B. Plus précisément, --cherry-pick --right-only --no-merges donne le
liste exacte.
--cerise
Un synonyme de --right-only --cherry-mark --no-merges ; utile pour limiter la sortie à
les commits de notre côté et marquer ceux qui ont été appliqués de l'autre côté d'un
historique fourchu avec git log --cherry en amont... mybranch, similaire à git cherry
ma branche en amont.
-g, --walk-reflogs
Au lieu de parcourir la chaîne d'ascendance de commit, parcourez les entrées de reflog à partir de la plus récente
un aux plus âgés. Lorsque cette option est utilisée, vous ne pouvez pas spécifier de commits à exclure
(C'est, ^ s'engager, commit1..commit2 et commit1... commit2 les notations ne peuvent pas être utilisées).
Avec --pretty format autre qu'une ligne (pour des raisons évidentes), cela provoque la sortie
d'avoir deux lignes d'informations supplémentaires tirées du reflog. Par défaut, commit@{Nième}
la notation est utilisée dans la sortie. Lorsque le commit de départ est spécifié comme commit@{maintenant},
la sortie utilise également commit@{horodatage} notation à la place. Sous --pretty=oneline, le
le message de validation est précédé de cette information sur la même ligne. Cette option ne peut pas
être combiné avec --reverse. Voir également git-reflog (1).
--fusionner
Après un échec de fusion, affichez les références qui touchent les fichiers en conflit et qui n'existent pas sur
toutes les têtes à fusionner.
--frontière
Sortie des commits de limite exclus. Les commits de limite sont préfixés par -.
Historique Simplification
Parfois, vous n'êtes intéressé que par des parties de l'historique, par exemple les commits
modifier un particulier . Mais il y a deux parties de Historique Simplification, une partie
est de sélectionner les commits et l'autre est de savoir comment le faire, car il existe différentes stratégies pour
simplifier l'histoire.
Les options suivantes sélectionnent les commits à afficher :
S'engage à modifier le donné sont sélectionnés.
--simplifier-par-décoration
Les commits référencés par une branche ou un tag sont sélectionnés.
Notez que des commits supplémentaires peuvent être affichés pour donner un historique significatif.
Les options suivantes affectent la manière dont la simplification est effectuée :
Mode par défaut
Simplifie l'historique à l'historique le plus simple expliquant l'état final de l'arbre.
Le plus simple car il élague certaines branches latérales si le résultat final est le même (c'est-à-dire
fusion de branches avec le même contenu)
--histoire complète
Identique au mode par défaut, mais n'élimine pas certains historiques.
--dense
Seuls les commits sélectionnés sont affichés, plus certains pour avoir un historique significatif.
--clairsemé
Tous les commits de l'historique simplifié sont affichés.
--simplify-fusions
Option supplémentaire à --full-history pour supprimer certaines fusions inutiles du résultat
historique, car il n'y a pas de commits sélectionnés contribuant à cette fusion.
--ascendance-chemin
Lorsqu'on lui donne une plage de commits à afficher (par exemple commit1..commit2 or commettre2 ^ commit1),
afficher uniquement les commits qui existent directement sur la chaîne d'ascendance entre le commettre1 et
commettre2, c'est-à-dire des commits descendants de commettre1, et ancêtres de commettre2.
Une explication plus détaillée suit.
Supposons que vous ayez spécifié foo comme . Nous appellerons des commits qui modifient foo !TREESAME,
et le reste TRESAME. (Dans un diff filtré pour foo, ils ont l'air différents et égaux,
respectivement.)
Dans la suite, nous nous référerons toujours au même exemple d'historique pour illustrer le
différences entre les paramètres de simplification. Nous supposons que vous filtrez un fichier
foo dans ce graphe de commit :
.-A---M---N---O---P---Q
/ / / / / /
IBCDEY
\ / / / / / /
`-------------' X
La ligne horizontale de l'historique A---Q est considérée comme le premier parent de chaque fusion. Les
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 je suis
! ARBORE.
· En A, foo ne contient que « foo ».
· B contient le même changement que A. Sa fusion M est triviale et donc TREESAME pour tous
Parents.
· C ne change pas foo, mais sa fusion N le change en "foobar", donc ce n'est pas TREESAME
à n'importe quel parent.
· D définit foo sur « baz ». Son O fusionné combine les cordes de N et D à « foobarbaz » ;
c'est-à-dire que ce n'est pas TREESAME pour aucun parent.
· E change quux en "xyzzy", et sa fusion P combine les chaînes en "quux xyzzy". P est
TREESAME à O, mais pas à E.
· X est un commit racine indépendant qui a ajouté un nouveau côté de fichier, et Y l'a modifié. Y est
TREESAME à X. Sa fusion Q a ajouté le côté à P, et Q est TREESAME à P, mais pas à Y.
rev-list revient en arrière dans l'historique, incluant ou excluant les commits selon que
--full-history et/ou parent rewriting (via --parents ou --children) sont utilisés. Les
les paramètres suivants sont disponibles.
Mode par défaut
Les commits sont inclus s'ils ne sont pas TREESAME envers un parent (bien que cela puisse être
modifié, voir --sparse ci-dessous). Si le commit était une fusion et qu'il s'agissait de TREESAME à un
parent, ne suivez que ce parent. (Même s'il y a plusieurs parents TREESAME, suivez
un seul d'entre eux.) Sinon, suivez tous les parents.
Cela se traduit par:
.-A---N---O
/ / /
IDENTIFIANT
Notez comment la règle de suivre uniquement le parent ARBRE, s'il y en a un, a été supprimée B
de la considération entièrement. C a été considéré via N, mais c'est TREESAME. Validation racine
sont comparés à un arbre vide, donc I est !TREESAME.
Les relations parent/enfant ne sont visibles qu'avec --parents, mais cela n'affecte pas le
commits sélectionnés en mode par défaut, nous avons donc montré les lignes parent.
--full-history sans réécriture du parent
Ce mode diffère du mode par défaut sur un point : suivez toujours tous les parents d'une fusion,
même si c'est TREESAME pour l'un d'eux. Même si plus d'un côté de la fusion a
commits qui sont inclus, cela n'implique pas que la fusion elle-même l'est ! Dans le
exemple, on obtient
IABNDOPQ
M a été exclu parce qu'il s'agit de TREESAME pour les deux parents. E, C et B ont tous été promenés,
mais seul B était !TREESAME, donc les autres n'apparaissent pas.
Notez que sans réécriture parentale, il n'est pas vraiment possible de parler de la
relations parent/enfant entre les commits, nous les montrons donc déconnectés.
--full-history avec réécriture du parent
Les commits ordinaires ne sont inclus que s'ils sont !TREESAME (bien que cela puisse être modifié,
voir --sparse ci-dessous).
Les fusions sont toujours incluses. Cependant, leur liste de parents est réécrite : le long de chaque
parent, supprimez les commits qui ne sont pas eux-mêmes inclus. Cela se traduit par
.-A---M---N---O---P---Q
/ / / / /
IB / D /
\ / / / /
'-------------'
Comparez avec --full-history sans réécrire ci-dessus. Notez que E a été élagué parce que
c'est TREESAME, mais la liste parent de P a été réécrite pour contenir le parent I de E. Le
la même chose s'est produite pour C et N, et X, Y et Q.
En plus des paramètres ci-dessus, vous pouvez modifier si TREESAME affecte l'inclusion :
--dense
Les engagements qui sont parcourus sont inclus s'ils ne sont pas TREESAME pour un parent.
--clairsemé
Tous les commits qui sont parcourus sont inclus.
Notez que sans --full-history, cela simplifie encore les fusions : si l'un des parents
est TREESAME, nous ne suivons que celui-là, donc les autres côtés de la fusion ne sont jamais
marchait.
--simplify-fusions
Tout d'abord, créez un graphique d'historique de la même manière que --full-history avec réécriture parent
fait (voir ci-dessus).
Ensuite, simplifiez chaque commit C à son remplacement C' dans l'historique final selon
les règles suivantes :
· Réglez C' sur C.
· Remplacer chaque parent P de C' par sa simplification P'. Dans le processus, laissez tomber
les parents qui sont des ancêtres d'autres parents ou qui sont root s'engage sur TREESAME
un arbre vide et supprimez les doublons, mais veillez à ne jamais laisser tomber tous les parents qui
nous sommes TREESAME à.
· Si après cette réécriture parent, C' est un commit racine ou de fusion (a zéro ou >1
parents), un commit de limite, ou !TREESAME, il reste. Sinon, il est remplacé
avec son seul parent.
L'effet de ceci est mieux montré en comparant à --full-history with parent
réécriture. L'exemple se transforme en :
.-A---M---N---O
/ / /
MICI
\ / /
'---------'
Notez les principales différences entre N, P et Q par rapport à --full-history :
· J'avais supprimé la liste des parents de N, car il s'agit d'un ancêtre de l'autre parent M.
Pourtant, N est resté parce que c'est !TREESAME.
· La liste des parents de P a été supprimée de la même manière. P a ensuite été complètement supprimé, car
il avait un parent et est TREESAME.
· La liste des parents de Q avait Y simplifié en X. X a ensuite été supprimé, car il s'agissait d'un
racine d'ARBRE. Q a ensuite été complètement supprimé, car il avait un parent et est
ARBORE.
Enfin, un cinquième mode de simplification est disponible :
--ascendance-chemin
Limitez les commits affichés à ceux directement sur la chaîne d'ascendance entre le « de »
et "to" commits dans la plage de commits donnée. C'est-à-dire n'afficher que les commits qui sont
ancêtre du commit « to » et descendants du commit « from ».
À titre d'exemple de cas d'utilisation, considérons l'historique de validation suivant :
D---E-------F
/ \ \
B---C---G---H---I---J
/ \
A-------K ---------------L--M
Un habitué D..M calcule l'ensemble des commits qui sont les ancêtres de M, mais exclut le
ceux qui sont les ancêtres de D. Ceci est utile pour voir ce qui est arrivé à l'histoire
menant à M depuis D, au sens où « qu'est-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, de
cours).
Quand on veut savoir quels commits de M sont contaminés par le bogue introduit par
D et doivent être corrigés, cependant, nous pourrions vouloir afficher uniquement le sous-ensemble de D..M Voilà
descendants de D, c'est-à-dire hors C et K. C'est exactement ce que
L'option --ancestry-path le fait. Appliqué à la D..M plage, il en résulte :
E ------- F
\ \
G---H---I---J
\
L-M
L'option --simplify-by-decoration vous permet de n'afficher qu'une vue d'ensemble du
topologie de l'historique, en omettant les commits qui ne sont pas référencés par des balises. Les engagements sont
marqué comme !TREESAME (en d'autres termes, conservé après les règles de simplification de l'historique décrites
ci-dessus) si (1) ils sont référencés par des balises, ou (2) ils modifient le contenu des chemins
donné sur la ligne de commande. Tous les autres commits sont marqués comme TREESAME (sous réserve d'être
simplifié loin).
S’ENGAGER COMMANDE
Par défaut, les commits sont affichés dans l'ordre chronologique inverse.
--date-ordre
Afficher aucun parent avant que tous ses enfants ne soient affichés, mais sinon, afficher les commits dans
l'ordre d'horodatage des commits.
--author-date-commande
Afficher aucun parent avant que tous ses enfants ne soient affichés, mais sinon, afficher les commits dans
l'ordre d'horodatage de l'auteur.
--topo-ordre
N'afficher aucun parent avant que tous ses enfants ne soient affichés et éviter d'afficher les commits sur
plusieurs lignes d'histoire entremêlées.
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 les amis avec
--date-order affiche les commits dans l'ordre d'horodatage : 8 7 6 5 4 3 2 1.
Avec --topo-order, ils afficheraient 8 6 5 3 7 4 2 1 (ou 8 7 4 2 6 5 3 1); certains plus âgés
les commits sont affichés avant les plus récents afin d'éviter d'afficher les commits de deux
piste de développement parallèle mélangée.
--sens inverse
Sortez les commits dans l'ordre inverse. Ne peut pas être combiné avec --walk-reflogs.
Exlcusion Traversée
Ces options sont principalement destinées à l'emballage des référentiels Git.
--no-walk[=(trié|non trié)]
Affichez uniquement les commits donnés, mais ne parcourez pas leurs ancêtres. Cela n'a aucun effet
si une plage est spécifiée. Si l'argument non trié est donné, les commits sont affichés dans
l'ordre qui leur a été donné sur la ligne de commande. Sinon (si trié ou si aucun argument n'a été
donné), les commits sont affichés dans l'ordre chronologique inverse par heure de commit. C'est pas possible
combiné avec --graph.
--faire-marcher
Remplace un précédent --no-walk.
S’ENGAGER formatage
--jolie[= ], --format=
Joliment imprimer le contenu des journaux de validation dans un format donné, où peuvent être
un une ligne, court, moyenne, plein, plus plein, email, brut, format: et
tformat :. Quand n'est aucune de ces réponses et a %espace réservé dedans, il
agit comme si --pretty=tformat : ont reçu.
Voir la section « JOLI FORMATS » pour quelques détails supplémentaires pour chaque format. Lorsque
= partie est omise, elle est par défaut moyenne.
Remarque : vous pouvez spécifier le joli format par défaut dans la configuration du référentiel (voir
git-config(1)).
--abbrev-commit
Au lieu d'afficher le nom complet de l'objet de validation hexadécimal de 40 octets, n'affichez qu'un
préfixe partiel. Un nombre de chiffres non par défaut peut être spécifié avec "--abbrev= "
(qui modifie également la sortie diff, si elle est affichée).
Cela devrait rendre "--pretty=oneline" beaucoup plus lisible pour les personnes utilisant
Bornes à 80 colonnes.
--no-abbrev-commit
Affiche le nom complet de l'objet de validation hexadécimal de 40 octets. Cela annule --abbrev-commit et
les options qui l'impliquent telles que "--oneline". Il remplace également le
log.abbrevCommit variable.
--une ligne
Ceci est un raccourci pour "--pretty=oneline --abbrev-commit" utilisé ensemble.
--encodage=
Les objets commit enregistrent l'encodage utilisé pour le message de journal dans leur encodage
entête; cette option peut être utilisée pour indiquer à la commande de recoder le message du journal de validation
dans l'encodage préféré par l'utilisateur. Pour les commandes autres que de plomberie, la 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
affichera l'objet textuellement ; cela signifie que les séquences invalides dans l'original
commit peut être copié dans la sortie.
--notes[= ]
Afficher les notes (voir notes git(1)) qui annotent le commit, lors de l'affichage du commit
message de journal. C'est la valeur par défaut pour les commandes git log, git show et git whatchanged
lorsqu'il n'y a pas d'option --pretty, --format ou --oneline sur la ligne de commande.
Par défaut, les notes affichées proviennent des références de notes répertoriées dans le core.notesRef et
notes.displayRef variables (ou les remplacements d'environnement correspondants). Voir git-config(1)
pour plus de détails.
Avec une option argument, afficher cette référence de notes au lieu des notes par défaut
réf. La référence spécifie le nom de référence complet lorsqu'il commence par refs/notes/ ; quand cela
commence par notes/, refs/ et sinon refs/notes/ est préfixé pour former un nom complet de
la réf.
Plusieurs options --notes peuvent être combinées pour contrôler quelles notes sont affichées.
Exemples : "--notes=foo" affichera uniquement les notes de "refs/notes/foo" ; "--notes=toto
--notes" affichera à la fois les notes de "refs/notes/foo" et de la ou des références de notes par défaut.
--pas de notes
Ne pas afficher les notes. Cela annule l'option --notes ci-dessus, en réinitialisant la liste des
notes refs à partir desquelles les notes sont affichées. Les options sont analysées dans l'ordre indiqué sur le
ligne de commande, donc par exemple "--notes --notes=foo --no-notes --notes=bar" ne s'affichera que
notes de "refs/notes/bar".
--show-notes[= ], --[no-]standard-notes
Ces options sont obsolètes. Utilisez plutôt les options --notes/--no-notes ci-dessus.
--montrer-signature
Vérifiez la validité d'un objet commit signé en passant la signature à gpg --verify
et afficher la sortie.
--date relative
Synonyme de --date=relative.
--date=
Ne prend effet que pour les dates affichées dans un format lisible par l'homme, comme lors de l'utilisation
--joli. La variable de configuration log.date définit une valeur par défaut pour le --date de la commande log
option. Par défaut, les dates sont affichées dans le fuseau horaire d'origine (soit celui du commité, soit
auteurs). Si -local est ajouté au format (par exemple, iso-local), le local de l'utilisateur
le fuseau horaire est utilisé à la place.
--date=relative affiche les dates relatives à l'heure actuelle, par exemple « il y a 2 heures ». Les
L'option -local ne peut pas être utilisée avec --raw ou --relative.
--date=local est un alias pour --date=default-local.
--date=iso (ou --date=iso8601) affiche les horodatages dans un format de type ISO 8601. Les
les différences par rapport au format strict ISO 8601 sont :
· un espace au lieu du délimiteur date/heure T
· un espace entre le temps 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 en stricte ISO 8601
le format.
--date=rfc (ou --date=rfc2822) affiche les horodatages au format RFC 2822, souvent trouvés dans
messages électroniques.
--date=short affiche uniquement la date, mais pas l'heure, au format AAAA-MM-JJ.
--date=raw affiche la date au format Git brut interne %s au format %z.
--date=format:... transmet le format... à votre système strftime. Utilisez --date=format:%c
pour afficher la date dans le format préféré des paramètres régionaux de votre système. Voir le manuel strftime pour
une liste complète des espaces réservés de format. Lors de l'utilisation de -local, la syntaxe correcte est
--date=format-local :....
--date=default est le format par défaut, et est similaire à --date=rfc2822, avec quelques
des exceptions:
· il n'y a pas de virgule après le jour de la semaine
· le fuseau horaire est omis lorsque le fuseau horaire local est utilisé
--Parents
Affichez également les parents du commit (sous la forme "commit parent..."). permet également
réécriture parentale, voir Historique Simplification ci-dessous.
--enfants
Affichez également les enfants du commit (sous la forme « commit child... »). permet également
réécriture parentale, voir Historique Simplification ci-dessous.
--gauche droite
Marquez de quel côté d'un diff symétrique un commit est accessible. S'engage de la gauche
côté sont préfixés par < et ceux de droite par >. Si combiné avec --boundary,
ces commits sont préfixés par -.
Par exemple, si vous avez cette topologie :
y---b---b branche B
/\/
/.
/ / \
o---x---a---une branche A
vous obtiendrez une sortie comme celle-ci :
$ git rev-list --left-right --boundary --pretty=une ligne A...B
>bbbbbbbb... 3e sur b
>bbbbbbbb... 2e sur b
<aaaaaaa... 3rd on a
<aaaaaaa... 2nd on a
-yyyyyyy... 1er sur b
-xx... 1er sur un
--graphique
Dessinez une représentation graphique textuelle de l'historique des commits sur le côté gauche
de la sortie. Cela peut entraîner l'impression de lignes supplémentaires entre les commits, afin
pour que l'historique du graphique soit tracé correctement. Ne peut pas être combiné avec --no-walk.
Cela permet la réécriture du parent, voir Historique Simplification ci-dessous.
Cela implique l'option --topo-order par défaut, mais l'option --date-order peut également
être spécifié.
--show-linear-break[= ]
Lorsque --graph n'est pas utilisé, toutes les branches d'historique sont aplaties, ce qui peut rendre difficile la
voir que les deux commits consécutifs n'appartiennent pas à une branche linéaire. Cette option
met une barrière entre eux dans ce cas. Si est spécifié, c'est le
chaîne qui sera affichée à la place de celle par défaut.
Diff formatage
Vous trouverez ci-dessous les options qui contrôlent le formatage de la sortie diff. Certains d'entre eux sont
propre à git-rev-liste(1), cependant d'autres options de diff peuvent être données. Voir git-diff-
fichiers(1) pour plus d'options.
-c
Avec cette option, la sortie diff pour un commit de fusion montre les différences de chacun des
les parents au résultat de la fusion simultanément au lieu d'afficher la différence par paire
entre un parent et le résultat un à la fois. De plus, il ne répertorie que les fichiers qui
ont été modifiés de tous les parents.
--cc
Cet indicateur implique l'option -c et compresse davantage la sortie du correctif en omettant
mecs inintéressants dont le contenu dans les parents n'a que deux variantes et la fusion
résultat en choisit un sans modification.
-m
Ce drapeau fait que les commits de fusion affichent le diff complet comme les commits normaux ; pour chaque
merge parent, une entrée de journal séparée et un diff sont générés. Une exception est que seulement
diff par rapport au premier parent est affiché lorsque l'option --first-parent est donnée ; dans ce
cas, la sortie représente les changements apportés par la fusion développement le courant d'alors
branche.
-r
Afficher les différences récursives.
-t
Affichez les objets de l'arborescence dans la sortie diff. Cela implique -r.
JOLIE FORMATS
Si le commit est une fusion, et si le joli-format n'est pas une ligne, email or brut, un
une ligne supplémentaire est insérée avant le Auteur : ligne. Cette ligne commence par « Fusionner : » et
les sha1s des commits ancestraux sont imprimés, séparés par des espaces. Notez que la liste
les commits ne sont pas nécessairement la liste des le parent s'engage si vous avez limité
votre vision de l'historique : par exemple, si vous ne vous intéressez qu'aux changements liés à 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 un
joli. option de configuration soit à un autre nom de format, soit à un Format: chaîne, comme
décrit ci-dessous (voir git-config(1)). Voici les détails des formats intégrés :
· une ligne
Celui-ci est conçu pour être le plus compact possible.
· court
s'engager
Auteur:
· moyenne
s'engager
Auteur:
Date:
· plein
s'engager
Auteur:
S'engager:
· plus plein
s'engager
Auteur:
Date d'auteur :
S'engager:
Date de validation:
De
De:
Date:
Objet : [PATCH]
· brut
Le brut format affiche l'intégralité de la validation exactement telle qu'elle est stockée dans l'objet de validation.
Notamment, les SHA-1 sont affichés en entier, que --abbrev ou
--no-abbrev sont utilisés, et parents informations montrent que le vrai parent s'engage, sans
prise en compte des greffons ou de la simplification de l'histoire. Notez que ce format affecte
la façon dont les commits sont affichés, mais pas la façon dont le diff est affiché, par exemple avec git log
--cru. Pour obtenir les noms d'objets complets dans un format diff brut, utilisez --no-abbrev.
· format:
Le format: format vous permet de spécifier les informations que vous souhaitez afficher.
Cela fonctionne un peu comme le format printf, à l'exception notable que vous obtenez un
nouvelle ligne avec %n au lieu de \n.
Par exemple, format : « Le auteur of %h était %un, %ar%nLe titre était >>%s<<%n" montrerait
quelque chose comme ça:
L'auteur de fe6e0ee était Junio C Hamano, il y a 23 heures
Le titre était >>t4119: test autocomputing -p pour l'entrée diff traditionnelle.<
Les espaces réservés sont :
· %H : commettre le hachage
· %h: hachage de commit abrégé
· %T: hachage d'arbre
· %t: hachage d'arbre abrégé
· %P: hachages parent
· %p: hachages parent abrégés
· %un: nom de l'auteur
· %un: nom de l'auteur (en respectant .mailmap, voir git-shortlog(1) ou blâme(1))
· %ae: e-mail de l'auteur
· %aE: email de l'auteur (en respectant le .mailmap, voir git-shortlog(1) ou blâme(1))
· %un d: date de l'auteur (le format respecte l'option --date=)
· %un d: date de l'auteur, style RFC2822
· %ar: date d'auteur, parent
· %à: date de l'auteur, horodatage UNIX
· %ai: date de l'auteur, format de type ISO 8601
· %aI: date d'auteur, format strict ISO 8601
· %cn: nom de l'auteur
· %cN: nom du committer (en respectant .mailmap, voir git-shortlog(1) ou blâme(1))
· %ce: e-mail du commiteur
· %cE: email du committer (en respectant .mailmap, voir git-shortlog(1) ou blâme(1))
· %CD: date du commiter (le format respecte l'option --date=)
· %CD: date de l'auteur, style RFC2822
· %cr: date de commit, relative
· %ct: date du commiteur, horodatage UNIX
· %ci: date de validation, format de type ISO 8601
· %cI: date de validation, format strict ISO 8601
· %d: noms de référence, comme l'option --decorate de journal git(1)
· %D: noms de référence sans l'enveloppe " (", ")".
· %e: encodage
· %s: matière
· %f: ligne d'objet épurée, adaptée à un nom de fichier
· %b: corps
· %B: corps brut (sujet et corps déballés)
· %N : commettre des notes
· %GG: message de vérification brut de GPG pour un commit signé
· %G?: affiche "G" pour une bonne signature, "B" pour une mauvaise signature, "U" pour une bonne,
signature non fiable et "N" pour aucune signature
· %GS: affiche le nom du signataire d'un commit signé
· %GK: affiche la clé utilisée pour signer un commit signé
· %gD: sélecteur de reflog, par exemple, refs/stash@{1}
· %gd : sélecteur de reflog raccourci, par exemple, stash@{1}
· %gn: reflog nom d'identité
· %gN: nom d'identité reflog (en respectant .mailmap, voir git-shortlog(1) ou git-
blâmer(1))
· %ge: reflog identité email
· %gE: reflog identité email (en respectant .mailmap, voir git-shortlog(1) ou git-
blâmer(1))
· %gs: sujet reflog
· %Crédit: changer la couleur en rouge
· %Cvert: passer la couleur au vert
· %Cbleu: changer la couleur en bleu
· %Créset: réinitialiser la couleur
· %C(...): spécification de la couleur, comme décrit dans l'option de configuration color.branch.* ; ajouter
auto, au début émet une couleur uniquement lorsque les couleurs sont activées pour la sortie du journal
(par color.diff, color.ui, ou --color, et en respectant les paramètres auto du
ancien si nous allons à un terminal). auto seul (c'est-à-dire %C(auto)) s'allumera
coloration automatique sur les espaces réservés suivants jusqu'à ce que la couleur soit à nouveau changée.
· %m: gauche, droite ou borne limite
· %n: nouvelle ligne
· %%: un cru %
· %x00: imprime un octet à partir d'un code hexadécimal
· %w([ [, [, ]]]): change la ligne de retour à la ligne, comme l'option -w de git-
journal abrégé (1).
· %<( [,trunc|ltrunc|mtrunc]): faire en sorte que l'espace réservé suivant prenne au moins N colonnes,
remplissage des espaces sur la droite si nécessaire. Tronquer éventuellement au début
(ltrunc), le milieu (mtrunc) ou la fin (trunc) si la sortie est plus longue que N
Colonnes. Notez que la troncature ne fonctionne correctement qu'avec N >= 2.
· %<|( ): faire en sorte que l'espace réservé suivant prenne au moins jusqu'à la Nième colonne, remplissage
espaces à droite si nécessaire
· %>( ), %>|( ): semblable à %<( ), %<|( ) respectivement, mais les espaces de remplissage
sur la gauche
· %>>( ), %>>|( ): semblable à %>( ), %>|( ) respectivement, sauf que si le
le prochain espace réservé prend plus d'espaces que prévu et il y a des espaces sur sa gauche,
utiliser ces espaces
· %><( ), %><|( ): semblable à % <( ), %<|( ) respectivement, mais en remplissant les deux
côtés (c'est-à-dire que le texte est centré)
Note
Certains espaces réservés peuvent dépendre d'autres options données au moteur de parcours de révision.
Par exemple, les options %g* reflog inséreront une chaîne vide à moins que nous ne soyons
parcourant les entrées reflog (par exemple, par git log -g). Les espaces réservés %d et %D utiliseront
le format de décoration "court" si --decorate n'était pas déjà fourni sur la commande
ligne.
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 espace réservé, les sauts de ligne qui précèdent immédiatement
l'expansion est supprimée 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é juste avant
l'expansion si et seulement si l'espace réservé se développe en une chaîne non vide.
· tformat :
Le tformat : le format fonctionne exactement comme Format:, sauf qu'il fournit "terminateur"
sémantique au lieu de sémantique "séparatrice". En d'autres termes, chaque commit a le
caractère de fin de message (généralement une nouvelle ligne) ajouté, plutôt qu'un séparateur
placé entre les entrées. Cela signifie que la saisie finale d'un format sur une seule ligne sera
se terminer correctement par une nouvelle ligne, tout comme le fait le format "oneline". Pour
Exemple:
$ git log -2 --pretty=format :%h 4da45bef \
| perl -pe '$_ .= " -- NO NEWLINE\n" sauf si /\n/'
4da45be
7134973 -- PAS DE NOUVELLE LIGNE
$ git log -2 --pretty=tformat:%h 4da45bef \
| perl -pe '$_ .= " -- NO NEWLINE\n" sauf si /\n/'
4da45be
7134973
De plus, toute chaîne non reconnue contenant un % est interprétée comme si elle avait
tformat : devant. Par exemple, ces deux sont équivalents :
$ git log -2 --pretty=tformat:%h 4da45bef
$ git log -2 --pretty=%h 4da45bef
COMMUNE DIFFÉRENT OPTIONS
-p, -u, --patch
Générer un patch (voir la section sur la génération de patchs).
-s, --pas de patch
Supprimer la sortie diff. Utile pour les commandes comme git show qui affichent le patch par
par défaut, ou pour annuler l'effet de --patch.
-U , --unifié=
Générer des différences avec lignes de contexte au lieu des trois habituelles. Implique -p.
--cru
Pour chaque commit, affichez un résumé des modifications en utilisant le format diff brut. Voir le "RAW
FORMAT DE SORTIE" de git-diff(1). Ceci est différent de l'affichage du journal lui-même
au format brut, ce que vous pouvez obtenir avec --format=raw.
--patch-avec-brut
Synonyme de -p --raw.
--minimal
Passez plus de temps pour vous assurer que la plus petite différence possible est produite.
--la patience
Générez un diff en utilisant l'algorithme "patience diff".
--histogramme
Générez un diff en utilisant l'algorithme "histogram diff".
--diff-algorithm={patience|minimal|histogramme|myers}
Choisissez un algorithme de différence. Les variantes sont les suivantes :
par défaut, myers
L'algorithme de base de diff gourmand. Actuellement, c'est la valeur par défaut.
minimal
Passez plus de temps pour vous assurer que la plus petite différence possible est produite.
patience
Utilisez l'algorithme "patience diff" lors de la génération de patchs.
histogramme
Cet algorithme étend l'algorithme de patience pour « prendre en charge les
éléments".
Par exemple, si vous avez configuré la variable diff.algorithm sur une valeur différente de celle par défaut et
voulez utiliser celui par défaut, alors vous devez utiliser l'option --diff-algorithm=default.
--stat[= [, [, ]]]
Générez un diffstat. Par défaut, autant d'espace que nécessaire sera utilisé pour le
partie nom de fichier, et le reste pour la partie graphique. La largeur maximale par défaut est le terminal
largeur, ou 80 colonnes s'il n'est pas connecté à un terminal, et peut être remplacé par .
La largeur de la partie nom de fichier peut être limitée en donnant une autre largeur
après une virgule. La largeur de la partie graphique peut être limitée en utilisant
--stat-graph-width= (affecte toutes les commandes générant un graphique de statistiques) ou par
paramètre diff.statGraphWidth= (n'affecte pas git format-patch). En donnant un
troisième paramètre , vous pouvez limiter la sortie au premier lignes, suivi
par ... s'il y en a plus.
Ces paramètres peuvent également être définis individuellement avec --stat-width= ,
--stat-name-width= et --stat-count= .
--numstat
Similaire à --stat, mais affiche le nombre de lignes ajoutées et supprimées en notation décimale et
chemin d'accès sans abréviation, pour le rendre plus convivial pour la machine. Pour les fichiers binaires,
sort deux - au lieu de dire 0 0.
--shortstat
Afficher uniquement la dernière ligne du format --stat contenant le nombre total de modifications
fichiers, ainsi que le nombre de lignes ajoutées et supprimées.
--dirstat[= ]
Affiche la distribution de la quantité relative de modifications pour chaque sous-répertoire. Les
le comportement de --dirstat peut être personnalisé en lui passant une liste séparée par des virgules de
paramètres. Les valeurs par défaut sont contrôlées par la variable de configuration diff.dirstat
(voir git-config(1)). Les paramètres suivants sont disponibles :
change
Calculez les nombres de dirstat en comptant les lignes qui ont été supprimées du
source ou ajouté à la destination. Cela ignore la quantité de code pur
mouvements dans un fichier. En d'autres termes, la réorganisation des lignes dans un fichier n'est pas
compté autant que les autres changements. C'est le comportement par défaut lorsqu'aucun paramètre
est donné.
lignes
Calculez les nombres de dirstat en effectuant l'analyse diff régulière basée sur la ligne, et
additionnant le nombre de lignes supprimées/ajoutées. (Pour les fichiers binaires, comptez les morceaux de 64 octets
à la place, puisque les fichiers binaires n'ont pas de concept naturel de lignes). C'est un plus
cher --dirstat comportement que les changements de comportement, mais cela compte
réarrangé les lignes dans un fichier autant que d'autres changements. La sortie résultante est
cohérent avec ce que vous obtenez des autres options --*stat.
fichiers
Calculez les numéros de dirstat en comptant le nombre de fichiers modifiés. Chacun a changé
le fichier compte également dans l'analyse dirstat. C'est le calcul le moins cher
--dirstat comportement, car il n'a pas du tout besoin de regarder le contenu du fichier.
accumulé
Comptez également les modifications dans un répertoire enfant pour le répertoire parent. Noter que
lors de l'utilisation du cumul, la somme des pourcentages rapportés peut dépasser 100 %. Les
le comportement par défaut (non cumulatif) peut être spécifié avec le non cumulatif
paramètre.
Un paramètre entier spécifie un pourcentage de coupure (3 % par défaut). Annuaires
contribuant moins que ce pourcentage des changements ne sont pas affichés dans la sortie.
Exemple : ce qui suit comptera les fichiers modifiés, tout en ignorant les répertoires avec moins
plus de 10 % du nombre total de fichiers modifiés et l'accumulation du nombre de répertoires enfants
dans les répertoires parents : --dirstat=files,10,cumulative.
--sommaire
Générer un résumé condensé des informations d'en-tête étendues telles que les créations, les renommages
et les changements de mode.
--patch-avec-stat
Synonyme de -p --stat.
-z
Séparez les commits avec des NUL au lieu de nouvelles lignes.
De plus, lorsque --raw ou --numstat a été donné, ne modifiez pas les noms de chemin et utilisez les NUL comme
terminateurs de champ de sortie.
Sans cette option, chaque sortie de chemin aura TAB, LF, des guillemets doubles et
caractères de barre oblique inverse remplacés par \t, \n, \", et \\, respectivement, et le nom de chemin
seront entourés de guillemets doubles si l'un de ces remplacements a eu lieu.
--nom-seulement
Afficher uniquement les noms des fichiers modifiés.
--nom-statut
Afficher uniquement les noms et l'état des fichiers modifiés. Voir la description du --diff-filter
option sur la signification des lettres d'état.
--sous-module[= ]
Spécifiez comment les différences dans les sous-modules sont affichées. Lorsque --submodule ou --submodule=log
est donné, le enregistrer format est utilisé. Ce format répertorie les commits dans la plage comme git-
sous-module(1) résumé fait. En omettant l'option --submodule ou en spécifiant
--submodule=short, utilise le court format. Ce format n'affiche que les noms des
commits au début et à la fin de la plage. Peut être modifié via le diff.submodule
variable de configuration.
--couleur[= ]
Afficher les diff. --color (c'est-à-dire sans =) est identique à --color=always.
peut être toujours, jamais ou automatique.
--sans couleur
Désactivez les différences colorées. C'est la même chose que --color=never.
--mot-diff[= ]
Afficher un mot diff, en utilisant le pour délimiter les mots modifiés. Par défaut, les mots sont
délimité par des espaces ; voir --word-diff-regex ci-dessous. Les par défaut à plaine,
et doit être l'un des :
couleur
Mettez en surbrillance les mots modifiés en utilisant uniquement des couleurs. Implique --color.
plaine
Afficher les mots sous la forme [-removed-] et {+added+}. Ne fait aucune tentative pour échapper au
délimiteurs s'ils apparaissent dans l'entrée, la sortie peut donc être ambiguë.
porcelaine
Utilisez un format de ligne spécial destiné à la consommation de scripts.
Les séries ajoutées/supprimées/inchangées sont imprimées au format diff unifié habituel,
commençant par un caractère +/-/` ` au début de la ligne et s'étendant jusqu'à
La fin de la ligne. Les nouvelles lignes dans l'entrée sont représentées par un tilde ~ sur une ligne
de son propre.
aucun
Désactivez à nouveau la différence de mots.
Notez que malgré le nom du premier mode, la couleur est utilisée pour mettre en évidence le changement
pièces dans tous les modes si activé.
--word-diff-regex=
Utilisation pour décider ce qu'est un mot, au lieu de considérer des séries de non-espaces pour
être un mot. Implique également --word-diff à moins qu'il n'ait déjà été activé.
Chaque match sans chevauchement du est considéré comme un mot. N'importe quoi entre
ces correspondances sont considérées comme des espaces et ignorées (!) dans le but de trouver
différences. Vous pouvez ajouter |[^[:space:]] à votre expression régulière pour faire
assurez-vous qu'il correspond à tous les caractères non blancs. Une correspondance qui contient une nouvelle ligne est
silencieusement tronqué (!) à la nouvelle ligne.
Par exemple, --word-diff-regex=. traitera chaque caractère comme un mot et,
en conséquence, montrez les différences caractère par caractère.
L'expression régulière peut également être définie via un pilote diff ou une option de configuration, voir
attributs git(1) ou git-config(1). Le donner remplace explicitement tout pilote diff ou
paramètre de configuration. Les pilotes Diff remplacent les paramètres de configuration.
--color-mots[= ]
Équivalent à --word-diff=color plus (si une expression régulière a été spécifiée)
--word-diff-regex= .
--pas de renommage
Désactiver la détection de renommage, même lorsque le fichier de configuration donne la valeur par défaut à faire
de sorte.
--Chèque
Avertir si des modifications introduisent des erreurs d'espacement. Ce qui est considéré comme des erreurs d'espace est
contrôlé par la configuration core.whitespace. Par défaut, les espaces de fin
(y compris les lignes qui se composent uniquement d'espaces) et un caractère d'espace qui est
immédiatement suivi d'un caractère de tabulation à l'intérieur du retrait initial de la ligne sont
considéré comme des erreurs d'espaces. Sort avec un statut différent de zéro si des problèmes sont détectés. Pas
compatible avec --exit-code.
--ws-error-highlight=
Mettez en surbrillance les erreurs d'espacement sur les lignes spécifiées par dans la couleur spécifiée par
color.diff.whitespace. est une liste séparée par des virgules de l'ancien, du nouveau contexte. Lorsque
cette option n'est pas donnée, seules les erreurs d'espacement dans les nouvelles lignes sont mises en évidence. Par exemple
--ws-error-highlight=new,old met en évidence les erreurs d'espace blanc à la fois supprimées et ajoutées
lignes. tout peut être utilisé comme un raccourci pour l'ancien, le nouveau, le contexte.
--index-complet
Au lieu de la première poignée de caractères, affichez le blob complet avant et après l'image
les noms d'objet sur la ligne "index" lors de la génération d'une sortie au format patch.
--binaire
En plus de --full-index, génère un diff binaire qui peut être appliqué avec git-apply.
--abbrev[= ]
Au lieu d'afficher le nom complet de l'objet hexadécimal de 40 octets dans la sortie au format diff-raw
et les lignes d'en-tête diff-tree, n'affichent qu'un préfixe partiel. Ceci est indépendant de la
--full-index option ci-dessus, qui contrôle le format de sortie diff-patch. Non par défaut
le nombre de chiffres peut être spécifié avec --abbrev= .
-B[ ][/ ], --break-rewrites[=[ ][/ ]]
Divisez les modifications de réécriture complètes en paires de suppression et de création. Cela sert deux
fins:
Cela affecte la façon dont un changement qui équivaut à une réécriture totale d'un fichier non comme une série
de suppression et d'insertion mélangées avec très peu de lignes qui correspondent
textuellement comme contexte, mais comme une seule suppression de tout l'ancien suivi d'un
insertion unique de tout ce qui est nouveau, et le nombre m contrôle cet aspect du -B
option (par défaut à 60%). -B/70% spécifie que moins de 30% de l'original doit
restent dans le résultat pour que Git le considère comme une réécriture totale (c'est-à-dire sinon le
le correctif résultant sera une série de suppressions et d'insertions mélangées avec le contexte
lignes).
Lorsqu'il est utilisé avec -M, un fichier totalement réécrit est également considéré comme la source d'un
renommer (généralement -M ne considère qu'un fichier qui a disparu comme source d'un renommage),
et le nombre n contrôle cet aspect de l'option -B (par défaut à 50 %). -B20%
précise qu'un changement avec ajout et suppression par rapport à 20 % ou plus de la
la taille du fichier sont éligibles pour être récupérées comme source possible de renommage en
un autre fichier.
-M[ ], --find-renames[= ]
Si vous générez des différences, détectez et signalez les changements de nom pour chaque validation. Pour les fichiers suivants
à travers les renommages tout en parcourant l'historique, voir --follow. Si n est spécifié, c'est un
seuil sur l'indice de similarité (c'est-à-dire quantité d'ajouts/suppressions par rapport au
taille du fichier). Par exemple, -M90% signifie que Git doit considérer une paire suppression/ajout comme un
renommer si plus de 90 % du fichier n'a pas changé. Sans signe %, le nombre est à
être lu comme une fraction, précédée d'un point décimal. C'est-à-dire que -M5 devient 0.5 et est
donc le même que -M50%. De même, -M05 est identique à -M5%. Pour limiter la détection à
renommer exactement, utilisez -M100%. L'indice de similarité par défaut est de 50 %.
-C[ ], --find-copies[= ]
Détecter les copies ainsi que les renommages. Voir aussi --find-copies-harder. Si n est spécifié, il
a la même signification que pour -M .
--trouver-des copies-plus difficiles
Pour des raisons de performances, par défaut, l'option -C ne trouve des copies que si le fichier d'origine
de la copie a été modifié dans le même ensemble de modifications. Ce drapeau fait inspecter la commande
fichiers non modifiés comme candidats pour la source de la copie. C'est un très cher
opération pour les grands projets, alors utilisez-le avec prudence. Donner plus d'une option -C
a le même effet.
-D, --irréversible-delete
Omettez la préimage pour les suppressions, c'est-à-dire n'imprimez que l'en-tête mais pas la différence entre les
preimage et /dev/null. Le patch résultant n'est pas destiné à être appliqué avec patch ou
git appliquer ; c'est uniquement pour les personnes qui veulent juste se concentrer sur l'examen de la
texte après le changement. De plus, la sortie manque manifestement d'assez d'informations pour
appliquer un tel patch à l'envers, même manuellement, d'où le nom de l'option.
Lorsqu'il est utilisé avec -B, omettez également la pré-image dans la partie de suppression d'un
supprimer/créer une paire.
-l
Les options -M et -C nécessitent un temps de traitement O(n^2) où n est le nombre de
cibles potentielles de renommage/copie. Cette option empêche l'exécution de la détection de renommage/copie
si le nombre de cibles de renommage/copie dépasse le nombre spécifié.
--diff-filter=[(A|C|D|M|R|T|U|X|B)...[*]]
Sélectionnez uniquement les fichiers ajoutés (A), copiés (C), supprimés (D), modifiés (M), renommés
(R), ont leur type (c'est-à-dire fichier régulier, lien symbolique, sous-module, ...) modifié (T), sont
Non fusionnés (U), sont inconnus (X) ou ont eu leur appariement brisé (B). Toute combinaison
des caractères de filtre (y compris aucun) peuvent être utilisés. Quand * (Tout ou rien) est ajouté
à la combinaison, tous les chemins sont sélectionnés s'il existe un fichier qui correspond à d'autres
critères dans la comparaison; s'il n'y a pas de fichier qui correspond à d'autres critères, rien
est sélectionné.
-S
Recherchez les différences qui modifient le nombre d'occurrences de la chaîne spécifiée
(c'est-à-dire ajout/suppression) dans un fichier. Destiné à l'usage du scripteur.
C'est utile lorsque vous recherchez un bloc de code exact (comme une structure) et que vous voulez
pour connaître l'historique de ce bloc depuis sa création : utilisez la fonction
itérativement pour réintroduire le bloc intéressant dans la pré-image dans -S, et continuer
jusqu'à ce que vous obteniez la toute première version du bloc.
-G
Recherchez les différences dont le texte du correctif contient des lignes ajoutées/supprimées qui correspondent .
Pour illustrer la différence entre -S --pickaxe-regex et -G , envisager
un commit avec le diff suivant dans le même fichier :
+ return !regexec(regexp, two->ptr, 1, ®match, 0);
...
- hit = !regexec(regexp, mf2.ptr, 1, ®match, 0);
Alors que git log -G"regexec\(regexp" affichera ce commit, git log -S"regexec\(regexp"
--pickaxe-regex ne le fera pas (car le nombre d'occurrences de cette chaîne n'a pas
monnaie).
Voir le pioche entrée dans gitdiffcore(7) pour plus d'informations.
--pioche-tout
Lorsque -S ou -G trouve un changement, affichez tous les changements dans cet ensemble de modifications, pas seulement le
fichiers qui contiennent le changement de .
--pioche-regex
Traiter le donné à -S en tant qu'expression régulière POSIX étendue pour correspondre.
-O
Sortez le patch dans l'ordre spécifié dans le , qui a un shell glob
motif par ligne. Cela remplace la variable de configuration diff.orderFile (voir git-
config(1)). Pour annuler diff.orderFile, utilisez -O/dev/null.
-R
Échangez deux entrées ; c'est-à-dire afficher les différences entre le fichier d'index ou le fichier sur disque et l'arborescence
Contenu.
--relative[= ]
Lorsqu'il est exécuté à partir d'un sous-répertoire du projet, il peut être dit d'exclure les modifications en dehors
le répertoire et afficher les chemins d'accès relatifs avec cette option. Quand tu n'es pas dans
un sous-répertoire (par exemple dans un référentiel nu), vous pouvez nommer le sous-répertoire à créer
la sortie par rapport à en donnant un comme argument.
-un texte
Traitez tous les fichiers comme du texte.
--ignorer-espace-at-eol
Ignorez les changements dans les espaces à EOL.
-b, --ignore-space-change
Ignorer les changements dans la quantité d'espaces. Cela ignore les espaces à la fin de la ligne et
considère que toutes les autres séquences d'un ou plusieurs caractères blancs sont équivalentes.
-w, --ignore-tout-espace
Ignorer les espaces lors de la comparaison de lignes. Cela ignore les différences même si une ligne a
espace où l'autre ligne n'en a pas.
--ignore-lignes-vides
Ignorez les modifications dont les lignes sont toutes vides.
--inter-hunk-context=
Afficher le contexte entre les différents morceaux, jusqu'au nombre de lignes spécifié, ainsi
fusionner des morceaux qui sont proches les uns des autres.
-W, --fonction-contexte
Montrez toutes les fonctions environnantes des changements.
--ext-diff
Autorise l'exécution d'un assistant diff externe. Si vous définissez un pilote de diff externe avec
attributs git(5), vous devez utiliser cette option avec journal git(1) et amis.
--no-ext-diff
Interdire les pilotes de diff externes.
--textconv, --no-textconv
Autoriser (ou interdire) l'exécution de filtres de conversion de texte externes lors de la comparaison de fichiers binaires
des dossiers. Voir attributs git(5) pour plus de détails. Parce que les filtres textconv sont généralement un
conversion à sens unique, le diff résultant est adapté à la consommation humaine, mais ne peut pas
sois appliqué. Pour cette raison, les filtres textconv sont activés par défaut uniquement pour git-
diffde Géographie (1) et avec la journal git(1), mais pas pour git-format-correctif(1) ou commandes de plomberie diff.
--ignore-submodules[= ]
Ignorer les modifications apportées aux sous-modules dans la génération diff. peut être soit "aucun",
"untracked", "dirty" ou "all", qui est la valeur par défaut. L'utilisation de « aucun » prendra en compte le
sous-module modifié lorsqu'il contient soit des fichiers non suivis ou modifiés, soit son HEAD
diffère du commit enregistré dans le superprojet et peut être utilisé pour remplacer n'importe quel
paramètres de la ignorer option git-config(1) ou gitmodules(5). Lorsque "non suivi" est
les sous-modules utilisés ne sont pas considérés comme sales lorsqu'ils ne contiennent que du contenu non suivi (mais
ils sont toujours analysés pour le contenu modifié). L'utilisation de "dirty" ignore toutes les modifications apportées au
arbre de travail des sous-modules, seules les modifications apportées aux commits stockés dans le superprojet sont
montré (c'était le comportement jusqu'à la 1.7.0). L'utilisation de « all » masque toutes les modifications apportées à
sous-modules.
--src-prefix=
Affiche le préfixe source donné au lieu de "a/".
--dst-prefix=
Afficher le préfixe de destination donné au lieu de "b/".
--pas de préfixe
N'affiche aucun préfixe de source ou de destination.
Pour des explications plus détaillées sur ces options courantes, voir aussi gitdiffcore (7).
GÉNÉRATEUR PATCHS avec -P
Lorsque "git-diff-index", "git-diff-tree" ou "git-diff-files" sont exécutés avec un -p option, "git
diff" sans le --cru option, ou "git log" avec l'option "-p", ils ne produisent pas le
sortie décrite ci-dessus ; à la place, ils produisent un fichier de correctif. Vous pouvez personnaliser la création
de ces correctifs via les variables d'environnement GIT_EXTERNAL_DIFF et GIT_DIFF_OPTS.
Ce que l'option -p produit est légèrement différent du format diff traditionnel :
1. Il est précédé d'un en-tête "git diff" qui ressemble à ceci :
diff --git a/fichier1 b/fichier2
Les noms de fichiers a/ et b/ sont les mêmes à moins qu'il ne s'agisse de renommer/copier. Surtout, même
pour une création ou une suppression, /dev/null est pas utilisé à la place de a/ ou b/
noms de fichiers.
Lorsque renommer/copier est impliqué, file1 et file2 affichent le nom du fichier source du
rename/copy et le nom du fichier que rename/copy produit, respectivement.
2. Il est suivi d'une ou plusieurs lignes d'en-tête étendues :
ancien mode
nouveau mode
mode fichier supprimé
nouveau mode de fichier
copier de
copier
renommer de
renommer en
indice de similitude
indice de dissemblance
indice ..
Les modes de fichier sont imprimés sous forme de nombres octaux à 6 chiffres, y compris le type de fichier et le fichier
bits d'autorisation.
Les noms de chemin dans les en-têtes étendus n'incluent pas les préfixes a/ et b/.
L'indice de similarité est le pourcentage de lignes inchangées, et l'indice de dissemblance
est le pourcentage de lignes modifiées. Il s'agit d'un nombre entier arrondi, suivi d'un
signe de pourcentage. La valeur de l'indice de similarité de 100 % est donc réservée à deux fichiers égaux,
alors que 100% de dissemblance signifie qu'aucune ligne de l'ancien fichier n'a été intégrée au nouveau
une.
La ligne d'index inclut la somme de contrôle SHA-1 avant et après le changement. Les est
inclus si le mode de fichier ne change pas ; sinon, des lignes séparées indiquent l'ancien
et le nouveau mode.
3. Les caractères TAB, LF, guillemets doubles et barre oblique inverse dans les chemins sont représentés par \t, \n,
\" et \\, respectivement. Si une telle substitution est nécessaire, l'ensemble
pathname est mis entre guillemets doubles.
4. Tous les fichiers file1 dans la sortie font référence à des fichiers avant la validation, et tous les fichiers file2
les fichiers font référence aux fichiers après la validation. Il est incorrect d'appliquer chaque changement à chaque
fichier séquentiellement. Par exemple, ce patch permutera a et b :
diff --git a/ab/b
renommer à partir d'un
renommer en b
diff --git a/bb/a
renommer de b
renommer en un
COMBINÉ DIFFÉRENT Format
Toute commande générant un diff peut prendre l'option -c ou --cc pour produire un combiné diff quand
montrant une fusion. Il s'agit du format par défaut lors de l'affichage des fusions avec git-diff(1) ou git-
montrer(1). Notez également que vous pouvez donner l'option -m à n'importe laquelle de ces commandes pour forcer
génération de différences avec les parents individuels d'une fusion.
A combiné diff le format ressemble à ceci :
diff --combiné décrit.c
index fabadb8,cc95eb0..4866510
--- a/décrire.c
+++ b/décrire.c
@@@ -98,20 -98,12 +98,20 @@@
retourner (a_date > b_date) ? -1 : (a_date == b_date) ? 0 : 1 ;
}
- description vide statique (car * arg)
-static void décrire (struct commit *cmit, int last_one)
++ static void describe(char *arg, int last_one)
{
+ caractère non signé sha1[20] ;
+ struct commit *cmit;
structure commit_list *liste;
int statique initialisé = 0 ;
struct commit_name *n;
+ si (get_sha1(arg, sha1) < 0)
+ utilisation(describe_usage);
+ cmit = lookup_commit_reference(sha1) ;
+ si (!cmit)
+ utilisation(describe_usage);
+
si (!initialisé) {
initialisé = 1 ;
for_each_ref(get_name);
1. Il est précédé d'un en-tête "git diff", qui ressemble à ceci (quand -c option est
utilisé):
diff --fichier combiné
ou comme ça (quand --cc option est utilisée):
diff --cc fichier
2. Il est suivi d'une ou plusieurs lignes d'en-tête étendues (cet exemple montre une fusion avec
deux parents) :
indice , ..
mode , ..
nouveau mode de fichier
mode fichier supprimé ,
La mode , .. n'apparaît que si au moins l'un des est
différent du reste. En-têtes étendus avec des informations sur les contenus détectés
mouvement (renommage et détection de copie) sont conçus pour fonctionner avec diff de deux
et ne sont pas utilisés par le format diff combiné.
3. Il est suivi d'un en-tête de deux lignes from-file/to-file
--- un fichier
+++ b/fichier
Similaire à l'en-tête à deux lignes pour le traditionnel unifiée diff, /dev/null est utilisé pour
signaler les fichiers créés ou supprimés.
4. Le format d'en-tête de morceau est modifié pour empêcher les gens de l'alimenter accidentellement à
patch -p1. Le format diff combiné a été créé pour l'examen des changements de validation de fusion, et
n'était pas destiné à s'appliquer. Le changement est similaire au changement de l'extension indice
en-tête:
@@@ @@@
Il y a (nombre de parents + 1) @ caractères dans l'en-tête de bloc pour les différences combinées
le format.
Contrairement au traditionnel unifiée format diff, qui montre deux fichiers A et B avec un seul
colonne qui a - (moins - apparaît dans A mais supprimé dans B), + (plus - manquant dans A mais
ajouté à B), ou le préfixe " " (espace — inchangé), ce format compare deux fichiers ou plus
fichier1, fichier2,... avec un fichier X, et montre en quoi X diffère de chacun des fichiersN. Une colonne
pour chacun des fichiers N est ajouté à la ligne de sortie pour noter en quoi la ligne de X est différente de
le
Un - caractère dans la colonne N signifie que la ligne apparaît dans le fichierN mais elle n'apparaît pas
dans le résultat. Un caractère + dans la colonne N signifie que la ligne apparaît dans le résultat,
et fileN n'a pas cette ligne (en d'autres termes, la ligne a été ajoutée, du point de
vue de ce parent).
Dans l'exemple de sortie ci-dessus, la signature de la fonction a été modifiée à partir des deux fichiers (d'où deux
- suppressions de file1 et file2, plus ++ pour signifier qu'une ligne qui a été ajoutée ne
apparaissent soit dans file1 soit dans file2). De plus, huit autres lignes sont identiques à partir de file1 mais ne
n'apparaît pas dans file2 (donc préfixé avec +).
Lorsqu'il est affiché par git diff-tree -c, il compare les parents d'un commit de fusion avec le merge
résultat (c'est-à-dire file1..fileN sont les parents). Lorsqu'il est affiché par git diff-files -c, il compare
les deux parents de fusion non résolus avec le fichier d'arbre de travail (c'est-à-dire que file1 est l'étape 2 aka
"notre version", file2 est l'étape 3 aka "leur version").
EXEMPLES
git log --no-merges
Afficher tout l'historique des commits, mais ignorer les fusions
git log v2.6.12.. inclure/pilotes scsi/scsi
Afficher tous les commits depuis la version v2.6.12 qui a changé n'importe quel fichier dans l'include/scsi ou
drivers/scsi sous-répertoires
git log --since="il y a 2 semaines" -- gitk
Afficher les modifications apportées au fichier au cours des deux dernières semaines connard. Le "--" est nécessaire pour
éviter toute confusion avec le une succursale nommé connard
git log --name-status release..test
Afficher les commits qui sont dans la branche "test" mais pas encore dans la branche "release",
ainsi que la liste des chemins que chaque commit modifie.
git log --suivre builtin/rev-list.c
Affiche les commits qui ont changé Builtin/rev-list.c, y compris les commits qui
avant que le fichier ne reçoive son nom actuel.
git log --branches --not --remotes=origine
Affiche tous les commits qui se trouvent dans l'une des branches locales mais pas dans le suivi à distance
succursales pour origine (ce que vous avez cette origine n'en a pas).
git log master --not --remotes=*/master
Affiche tous les commits qui sont dans le maître local mais pas dans un maître de référentiel distant
branches.
git log -p -m --first-parent
Affiche l'historique, y compris les différences de changement, mais uniquement du point de vue de la « branche principale »,
ignorer les commits provenant de branches fusionnées et afficher les différences complètes des modifications
introduits par les fusions. Cela n'a de sens que si l'on suit une politique stricte de
fusion de toutes les branches thématiques en restant sur une seule branche d'intégration.
git log -L '/int main/',/^}/:main.c
Montre comment la fonction main() dans le fichier main.c a évolué au fil du temps.
journal git -3
Limite le nombre de commits à afficher à 3.
DISCUSSION
Git est dans une certaine mesure agnostique en matière de codage de caractères.
· Le contenu des objets blob sont des séquences d'octets non interprétées. Il n'y a pas
traduction de codage au niveau de base.
· Les noms de chemin sont codés dans le formulaire de normalisation UTF-8 C. Cela s'applique aux objets arborescents,
le fichier d'index, les noms de référence, ainsi que les noms de chemin dans les arguments de la ligne de commande,
variables d'environnement et fichiers de configuration (.git/config (voir git-config(sept)), gitignore(5),
attributs gitde Géographie (5) et avec la gitmodules(5)).
Notez que Git au niveau du noyau traite les noms de chemin simplement comme des séquences de non-NUL
octets, il n'y a pas de conversions de codage de nom de chemin (sauf sur Mac et Windows).
Par conséquent, l'utilisation de noms de chemin non ASCII fonctionnera principalement même sur les plates-formes et les fichiers
systèmes qui utilisent des codages ASCII étendus hérités. Cependant, les référentiels créés sur
de tels systèmes ne fonctionneront pas correctement sur les systèmes basés sur UTF-8 (par exemple Linux, Mac, Windows)
et vice versa. De plus, de nombreux outils basés sur Git supposent simplement que les noms de chemin sont
UTF-8 et ne parviendra pas à afficher correctement les autres encodages.
· Les messages de journal de validation sont généralement encodés en UTF-8, mais d'autres encodages ASCII étendus
sont également pris en charge. Cela inclut ISO-8859-x, CP125x et bien d'autres, mais pas
Encodages multi-octets UTF-16/32, EBCDIC et CJK (GBK, Shift-JIS, Big5, EUC-x, CP9xx
etc).
Bien que nous encourageons que les messages du journal de validation soient codés en UTF-8, le noyau et
Git Porcelain est conçu pour ne pas forcer UTF-8 sur les projets. Si tous les participants d'un
projet particulier trouve plus pratique d'utiliser des encodages hérités, Git n'interdit pas
ce. Cependant, il y a quelques choses à garder à l'esprit.
1. jet commettre et jet arbre de validation émet un avertissement si le message de journal de validation lui est donné
ne ressemble pas à une chaîne UTF-8 valide, à moins que vous ne disiez explicitement que votre projet utilise un
codage hérité. La façon de dire cela est d'avoir i18n.commitencoding dans .git/config
fichier, comme ceci :
[i18n]
codage de validation = ISO-8859-1
Les objets de validation créés avec le paramètre ci-dessus enregistrent la valeur de i18n.commitencoding
dans son en-tête d'encodage. C'est pour aider d'autres personnes qui les regarderont plus tard. Manque de
cet en-tête implique que le message de journal de validation est encodé en UTF-8.
2. jet enregistrer, jet montrer, jet blâmer et les amis regardent l'en-tête d'encodage d'un commit
objet et essayez de recoder le message de journal en UTF-8, sauf indication contraire. Tu
peut spécifier l'encodage de sortie souhaité avec i18n.logoutputencoding dans .git/config
fichier, comme ceci :
[i18n]
codage de sortie = ISO-8859-1
Si vous n'avez pas cette variable de configuration, la valeur de i18n.commitencoding est
utilisé à la place.
Notez que nous avons délibérément choisi de ne pas recoder le message du journal de commit lorsqu'un commit est
fait pour forcer UTF-8 au niveau de l'objet de validation, car le recodage en UTF-8 n'est pas
nécessairement une opération réversible.
CONFIGURATION
See git-config(1) pour les variables de base et git-diff(1) pour les réglages liés au diff
génération.
format.jolie
Valeur par défaut pour l'option --format. (Voir Assez Formats ci-dessus.) La valeur par défaut est moyenne.
i18n.logOutputEncoding
Codage à utiliser lors de l'affichage des logs. (Voir Discussions ci-dessus.) La valeur par défaut est
i18n.commitEncoding si défini, et UTF-8 sinon.
journal.date
Format par défaut pour les dates lisibles par l'homme. (Comparez l'option --date.) La valeur par défaut est
"default", ce qui signifie écrire des dates comme le samedi 8 mai 19:35:34 2010 -0500.
log.suivre
Si vrai, git log agira comme si l'option --follow était utilisée lorsqu'un seul est
étant donné. Cela a les mêmes limitations que --follow, c'est-à-dire qu'il ne peut pas être utilisé pour suivre
plusieurs fichiers et ne fonctionne pas bien sur l'historique non linéaire.
log.showRoot
Si false, git log et les commandes associées ne traiteront pas le commit initial comme un gros
événement de création. Tout commit racine dans la sortie git log -p serait affiché sans diff
ci-joint. La valeur par défaut est true.
plan de messagerie.*
See git-shortlog (1).
notes.displayRef
Quelles références, en plus de la valeur par défaut définie par core.notesRef ou GIT_NOTES_REF, lire
notes de lors de l'affichage des messages de validation avec la famille de commandes de journal. Voir git-
note (1).
Peut être un nom de référence non abrégé ou un glob et peut être spécifié plusieurs fois. UNE
un avertissement sera émis pour les références qui n'existent pas, mais un glob qui ne correspond à aucune
refs est ignoré en silence.
Ce paramètre peut être désactivé par l'option --no-notes, remplacé par le
GIT_NOTES_DISPLAY_REF variable d'environnement, et remplacée par --notes=
option.
GIT
Une partie de l' jet(1) Suite
Utilisez git-log en ligne en utilisant les services onworks.net
