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.47.1 no changes
- 2.47.0 10/06/24
- 2.46.1 → 2.46.2 no changes
- 2.46.0 07/29/24
- 2.45.1 → 2.45.2 no changes
- 2.45.0 04/29/24
- 2.44.1 → 2.44.2 no changes
- 2.44.0 02/23/24
- 2.43.2 → 2.43.5 no changes
- 2.43.1 02/09/24
- 2.43.0 11/20/23
- 2.42.2 → 2.42.3 no changes
- 2.42.1 11/02/23
- 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.3 → 2.37.7 no changes
- 2.37.2 08/11/22
- 2.36.1 → 2.37.1 no changes
- 2.36.0 04/18/22
- 2.34.1 → 2.35.8 no changes
- 2.34.0 11/15/21
- 2.33.1 → 2.33.8 no changes
- 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.25.2 → 2.27.1 no changes
- 2.25.1 02/17/20
- 2.25.0 01/13/20
- 2.24.1 → 2.24.4 no changes
- 2.24.0 11/04/19
- 2.22.1 → 2.23.4 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.19.1 no changes
- 2.19.0 09/10/18
- 2.18.1 → 2.18.5 no changes
- 2.18.0 06/21/18
- 2.17.1 → 2.17.6 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 no changes
- 2.9.5 07/30/17
- 2.8.6 07/30/17
- 2.7.6 no changes
- 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.1.4 → 2.2.3 no changes
- 2.0.5 12/17/14
SYNOPSIS
git diff [<options>] [<commit>] [--] [<chemin>…] git diff [<options>] --cached [--merge-base] [<commit>] [--] [<chemin>…] git diff [<options>] [--merge-base] <commit> [<commit>…]<commit> [--] [<chemin>…] git diff [<options>] <commit>…<commit> [--] [<chemin>…] git diff [<options>] <blob> <blob> git diff [<options>] --no-index [--] <chemin> <chemin>
DESCRIPTION
Affiche les modifications entre l’arbre de travail et l’index ou un arbre, les modifications entre l’index et un arbre, les modifications entre deux arbres, les modifications résultant d’une fusion, les modifications entre deux objets blobs ou les modifications entre deux fichiers sur disque.
- git diff [<options>] [--] [<chemin>…]
-
Cette forme sert à visualiser les modifications que vous avez faites par rapport à l’index (la zone de préparation du prochain commit). En d’autres termes, les différences sont ce que vous pourriez indiquer à Git d’ajouter à l’index mais que vous n’avez pas encore ajoutées. Vous pouvez indexer ces modifications en utilisant git-add[1].
- git diff [<options>] --no-index [--] <chemin> <chemin>
-
Cette forme sert à comparer les deux chemins indiqués sur le système de fichiers. Vous pouvez omettre l’option
--no-index
si la commande est lancée dans un arbre de travail contrôlé par Git et qu’au moins un des chemins pointe hors de l’arbre de travail ou si la commande est lancée hors d’un arbre de travail contrôlé par Git. Cette forme implique--exit-code
. - git diff [<options>] --cached [--merge-base] [<commit>] [--] [<chemin>…]
-
Cette forme sert à visualiser les modifications que vous avez indexées pour la prochaine validation vis-à-vis du <commit> nommé. Typiquement, vous voudriez comparer avec le commit le plus récent (HEAD), ce qui est fait automatiquement si vous ne spécifiez pas <commit>. Si HEAD n’existe pas (par exemple, des branches à naître) et si <commit> n’est pas fourni, les modifications indexées sont affichées. --staged est synonyme de --cached.
Si --merge-base est donné, au lieu d’utiliser <commit>, utiliser la base de fusion de <commit> et HEAD.
git diff --cached --merge-base A
est équivalent àgit diff --cached $(git merge-base A HEAD)
. - git diff [<options>] [--merge-base] <commit> [--] [<chemin>…]
-
Cette forme sert à visualiser les modifications présentes dans l’arbre de travail par rapport au <commit> indiqué. Vous pouvez utiliser HEAD pour le comparer au commit le plus récent ou un nom de branche pour le comparer avec le sommet d’une branche différente.
Si --merge-base est donné, au lieu d’utiliser <commit>, utiliser la base de fusion de <commit> et HEAD.
git diff --merge-base A
est équivalent àgit diff $(git merge-base A HEAD)
. - git diff [<options>] [--merge-base] <commit> <commit> [--] [<chemin>…]
-
Ceci sert à visualiser les modifications entre deux <commit> arbitraires.
Si --merge-base est donné, utiliser la base de fusion des deux commits pour le côté "before".
git diff --merge-base A B
est équivalent àgit diff $ (git merge-base A B) B
. - git diff [<options>] <commit> <commit>…<commit> [--] [<chemin>…]
-
Cette forme permet de visualiser les résultats d’un commit de fusion. Le premier <commit> indiqué doit être la fusion elle-même ; les deux autres commits ou plus doivent être ses parents. Des façons pratiques de produire l’ensemble des révisions souhaitées sont d’utiliser les suffixes
^@
et^!`Si A est un commit de fusion, alors `git diff A A^@
,git diff A^!
etgit show A
donnent tous la même différence combinée. - git diff [<options>] <commit>..<commit> [--] [<chemin>…]
-
Cette forme est synonyme de la forme précédente (sans le
..
) pour visualiser les modification entre deux <commit>s arbirtraires. Si <commit> est omis d’un côté, cela aura le même effet que de spécifier HEAD à la place. - git diff [<options>] <commit>...<commit> [--] [<chemin>…]
-
Cette forme sert à visualiser les modifications sur la branche contenant et jusqu’au second <commit>, en débutant à l’ancêtre commun au deux <commit>.
git diff A\...B
est équivalent àgit diff $(git merge-base A B) B
. Vous pouvez omettre l’un ou l’autre <commit>, ce qui a le même effet que de spécifier HEAD à la place.
Juste au cas où vous feriez quelque chose d’exotique, il convient de noter que la totalité des <commits> de la description ci-dessus, sauf dans le cas --merge-base
et dans les deux dernières formes qui utilisent les notations ..
, peut être n’importe quel <arbre>. Un arbre intéressant est celui pointé par la réf nommée AUTO_MERGE', qui est écrit par la stratégie de fusion 'ort' lors de conflits de fusions (voir git-merge[1]). La comparaison de l'arbre de travail avec `AUTO_MERGE
montre les modifications que vous avez apportées jusqu’à présent pour résoudre les conflits textuels (voir les exemples ci-dessous).
Pour une liste plus complète des moyens de spécifier <commit>, voir la section « SPÉCIFIER LES RÉVISIONS » dans gitrevisions[7]. Cependant, "diff" concerne la comparaison de deux point finaux, et non d’intervalles, et les notations d’intervalle (<commit>..<commit>
et <commit>\...<commit>
) ne réfèrent pas un intervalle tel que défini dans la section « SPÉCIFIER LES RÉVISIONS » de gitrevisions[7].
OPTIONS
- -p
- -u
- --patch
-
Générer la rustine (voir Génération du texte de rustine avec -p). C’est l’option par défaut.
- -s
- --no-patch
-
Supprimer la sortie de la machinerie diff. Utile pour éliminer la sortie des commandes telles que
git show
qui affichent la rustine par défaut, ou pour supprimer l’effet d’options telles que--patch
, `--stat`qui auraient pu être incluse plus tôt sur la ligne de commande via un alias. - -U<n>
- --unified=<n>
-
Générer des diffs avec <n> lignes de contexte au lieu des trois habituelles. Implique
--patch
. - --output=<fichier>
-
Sortie vers un fichier spécifique au lieu de stdout.
- --output-indicator-new=<caractère>
- --output-indicator-old=<caractère>
- --output-indicator-context=<caractère>
-
Spécifier le caractère utilisé pour indiquer les lignes nouvelles, anciennes ou contextuelles dans la rustine générée. Normalement, il s’agit de +, - et ' ' respectivement.
- --raw
-
Genérer la diff en format brut.
- --patch-with-raw
-
Synonyme de
-p --raw
. - --indent-heuristic
-
Activer l’heuristique qui décale les limites des sections de diff pour rendre les rustines plus faciles à lire. C’est l’option par défaut.
- --no-indent-heuristic
-
Désactiver l’heuristique d’indentation.
- --minimal
-
Passer plus de temps pour s’assurer que le diff le plus petit possible est produit.
- --patience
-
Générer un diff en utilisant l’algorithme « patience diff ».
- --histogram
-
Générer un diff en utilisant l’algorithme « diff histogramme ».
- --anchored=<texte>
-
Générer un diff en utilisant l’algorithme « diff ancré ».
Cette option peut être spécifiée plus d’une fois.
Si une ligne existe dans la source et la destination, n’existe qu’une seule fois, et démarre avec ce texte, cet algorithme tente d’empêcher qu’elle apparaisse comme une suppression ou une addition dans la sortie. L’algorithme « patience diff » est utilisé en interne.
- --diff-algorithm={patience|minimal|histogram|myers}
-
Choisir un algorithme de diff. Les variantes sont comme suit :
-
default
,myers
-
L’algorithme de diff avide. C’est actuellement celui par défaut.
-
minimal
-
Passer plus de temps pour s’assurer que le diff le plus petit possible est produit.
-
patience
-
Utiliser l’algorithme « patience diff » pour la génération de rustine.
-
histogram
-
Cet algorithme étend l’algorithme patience pour « supporter les éléments communs de faible fréquence ».
Par exemple, si vous avez configuré la variable
diff.algorithm
à une valeur autre que celle par défaut et souhaitez utiliser la valeur par défaut, alors vous devez utiliser l’option--diff-algorithm=default
. -
- --stat[=<largeur>[,<largeur-de-nom>[,<nombre>]]]
-
Générer un diffstat. Par défaut, autant d’espace que nécessaire sera utilisé pour la partie du nom de fichier et le reste pour la partie de graphe. La largeur maximum est par défaut la largeur du terminal, ou 80 colonnes si non connecté à un terminal, et peut être outrepassé avec
<largeur>
. La largeur du nom de fichier peut être limitée en fournissant une autre largeur<largeur-de-nom>
après une virgule ou en réglantdiff.statNameWidth=<largeur>
. La largeur de la partie du graphe peut être limitée en utilisant--stat-graph-width=<largeur> ou en réglant `diff.statGraphWidth=<largeur>
. L’utilisation de--stat
ou--stat-graph-width
affecte toutes les commandes qui génèrent un graphique de stat, tandis que réglerdiff.statNameWidth
ordiff.statGraphWidth
n’affecte pasgit format-patch
. En ajoutant un troisième paramètre<nombre>
, vous pouvez limiter la sortie aux premières<nombre>
lignes, suivies de...
s’il y en a plus.Ces paramètres peuvent aussi être positionnés individuellement avec
--stat-width=<largeur>
,--stat-name-width=<largeur-de-nom>
et--stat-count=<nombre>
. - --compact-summary
-
Afficher un résumé condensé de l’information d’entête étendu telle que les créations ou les suppressions de fichier (« nouveau » ou « disparu », optionnellement « +l » si c’est un lien symbolique) et les modifications de mode (« +x » ou « -x » pour l’ajout et la suppression du bit exécutable respectivement) dans le diffstat. L’information est affichée entre la partie nom de fichier et la partie graphe. Implique
--stat
. - --numstat
-
Similaire à
--stat
, mais afficher le nombre de lignes ajoutées ou supprimées en notation décimale et le nom de chemin sans abréviation, pour le rendre plus facile à traiter automatiquement. Pour les fichiers binaires, affiche deux-
au lieu de0 0
. - --shortstat
-
N’affiche que la dernière ligne du format
--stat
contenant le nombre total de fichiers modifiés, de même que le nombre de lignes ajoutées et supprimées. - -X[<param1,param2,…>]
- --dirstat[=<param1,param2,…>]
-
Afficher la distribution de la quantité relative de modifications pour chaque sous-répertoire. Le comportement de
--dirstat
peut être personnalisé en lui passant une liste de paramètres séparés par des virgules. Les valeurs par défaut sont contrôlées par la variable de configurationdiff.dirstat
(voir git-config[1]). Les paramètres suivants sont disponibles :-
changes
-
Calculer les valeurs de dirstat en comptant les lignes supprimées de la source ou ajoutées dans la destination. Ceci ignore la quantité de purs mouvements de code dans un fichier. En d’autres termes, le réarrangement de lignes dans un fichier n’est pas compté autant que les autres modifications. C’est le comportement par défaut quand aucun paramètre n’est fourni.
-
lines
-
Calculer les valeurs dirstat en faisant l’analyse diff normal par ligne, et en additionnant les totaux de lignes ajoutées/supprimées. (Pour les fichiers binaires, compter plutôt les sections de 64 octets, puisque les fichiers binaires n’ont pas de concept de ligne). C’est un comportement de
--dirstat
plus onéreux que le comportementchanges
, mais il compte les lignes réarrangées dans un fichier autant que les autres modifications. La sortie résultante est cohérente avec ce que vous obtiendriez avec d’autres options--*stat
. -
files
-
Calculer les valeurs dirstat en comptant le nombre de fichiers changés. Chaque fichier modifié compte de façon égale dans l’analyse dirstat. C’est le comportement
--dirstat
le moins cher en termes de calcul, puisqu’il n’a pas du tout besoin d’analyser le contenu du fichier. -
cumulative
-
Compter les modifications dans un répertoire enfant pour le répertoire parent. Notez qu’en utilisant
cumulative
, la somme des pourcentages constatés peut dépasser 100 %. Le comportement par défaut (non cumulatif) peut être spécifié avec le paramètrenoncumulative
. - <limite>
-
Un paramètre entier qui spécifie un pourcentage limite (3% par défaut). Les répertoires contribuant moins que ce pourcentage de modifications ne sont pas affichés dans la sortie.
Exemple : ce qui suit va compter les fichiers modifiés, tout en ignorant les répertoires qui contiennent moins de 10 % de la quantité totale de fichiers modifiés et en accumulant les totaux des répertoires enfants dans les répertoires parents :
--dirstat=files,10,cumulative
. -
- --cumulative
-
Synonyme de --dirstat=cumulative
- --dirstat-by-file[=<param1,param2>…]
-
Synonyme de --dirstat=files,<param1>,<param2>….
- --summary
-
Afficher un résumé condensé d’information d’entête étendu tel que les créations, les renommages et les modifications de mode.
- --patch-with-stat
-
Synonyme de
-p --stat
. - -z
-
Quand
--raw
,--numstat
,--name-only
ou--name-status
a été fourni, ne pas modifier les noms de chemin et utiliser des NULs comme terminateurs de champs.Sans cette option, les noms de chemin avec des caractères « inhabituels » sont cités comme expliqué pour la variable de configuration
core.quotePath
(voir git-config[1]). - --name-only
-
Afficher uniquement le nom de chaque fichier modifié dans l’arbre post-image. Les noms de fichiers sont souvent encodés en UTF-8. Le définir sur
none
rend la sortie de blâme des données non converties. Pour plus d’informations, voir la discussion sur l’encodage dans la page manuelle git-log[1]. - --name-status
-
N’afficher que le ou les noms et statuts de fichier modifié. Voir la description de l’option
--diff-filter
pour la signification des lettres de statut. Tout comme--name-only
, les noms de fichiers sont souvent encodés en UTF-8. - --submodule[=<format>]
-
Spécifier comment les différences dans les sous-modules sont affichées. Lorsque vous spécifiez
--submodule=short
, le format short (court) est utilisé. Ce format n’affiche que le nom des commits du début et de la fin de la plage. Quand--submodule
ou--submodule=log
est spécifié, le format log (journal) est utilisé. Ce format liste les commits dans la plage comme le faitsummary
de git-submodule[1]. Quand--submodule=diff
est spécifié, le format diff est utilisé. Ce format affiche une diff en ligne des modifications dans le sous-module pour la plage de commits. Vaut par défautdiff.submodule
ou le format short si l’option de configuration n’est pas renseignée. - --color[=<quand>]
-
Afficher des diff colorés.
--color
(sans =<quand>) est identique à--color=always
. <quand> peut êtrealways
,never
ouauto
. Ceci peut être changé par les réglages de configurationcolor.ui
etcolor.diff
. - --no-color
-
Désactiver les diff colorés. Ceci peut être utilisé pour outrepasser les réglages de configuration. C’est identique à
--color=never
. - --color-moved[=<mode>]
-
Les lignes de code déplacées sont colorées différemment. Ceci peut être modifié par le réglage de configuration
diff.colorMoved
. Le <mode> vaut par défaut no si l’option n’est pas fournie et zebra si l’option est fournie sans mode. Le mode est une valeur parmi :- no
-
Les lignes déplacées ne sont pas surlignées.
- default
-
C’est un synonyme de
zebra
. Cela peut changer pour un mode plus raisonnable dans le futur. - plain
-
Toute ligne qui est ajoutée à un endroit et supprimée à un autre endroit sera colorée avec color.diff.newMoved. Similairement color.diff.oldMoved sera utilisé pour les lignes retirées qui ont été ajoutées ailleurs dans le diff. Ce mode prend n’importe quelle ligne déplacée, mais il n’est pas très utile dans une revue pour déterminer si un bloc de code a été déplacé sans permutation.
- blocks
-
Les blocs de texte déplacé d’au moins 20 caractères alphanumériques sont détectés avidement. Les blocs détectés sont peints avec les couleurs color.diff.oldMoved pour l’ancienne place et color.diff.newMoved pour la nouvelle place. Les blocs adjacents ne peuvent pas être différenciés.
- zebra
-
Les blocs de texte déplacé sont détectés comme dans le mode blocks. Les blocs sont peints en utilisant la couleur color.diff.{old,new}Moved ou color.diff.{old,new}MovedAlternative. La différence entre les deux couleurs indique qu’un nouveau bloc a été détecté.
- dimmed-zebra
-
Similaire à zebra, mais avec une limitation supplémentaire des parties inintéressantes du code déplacé. Les lignes de frontière de deux blocs adjacents sont considérées intéressantes, le reste est inintéressant.
dimmed_zebra
est un synonyme déconseillé.
- --no-color-moved
-
Désactiver la détection de déplacement. Ce peut être utilisé pour outrepasser les réglages de configuration. C’est comme
--color-moved=no
. - --color-moved-ws=<modes>
-
Ceci configure comment les espaces sont ignorés lors de la détection de déplacement par
--color-moved
. Le réglage de configurationdiff.colorMovedWS
permet de le modifier. Ces modes peuvent être fournis comme une liste séparée par des virgules :- no
-
Ne pas ignorer les espaces lors de la détection de déplacement.
- ignore-space-at-eol
-
Ignorer les modifications d’espaces en fin de ligne.
- ignore-space-change
-
Ignorer les modifications de nombre d’espaces. Cela ignore les espaces en fin de ligne et considère toutes les autres séquences d’un caractère blanc ou plus comme équivalentes.
- ignore-all-space
-
Ignorer les espaces lors de la comparaison de lignes. Ceci ignore les différences même si une ligne a des espaces quand l’autre n’en a aucun.
- allow-indentation-change
-
Ignorer initialement tout espace lors de la détection de déplacement, puis grouper les blocs de code déplacé dans un bloc si la modification de blancs est identique par ligne. C’est incompatible avec les autres modes.
- --no-color-moved-ws
-
Ne pas ignorer les blancs lors de la détection de déplacement. Ceci peut être utilisé pour outrepasser les réglages de configuration. C’est identique à
--color-moved-ws=no
. - --word-diff[=<mode>]
-
Afficher un diff par mot, en utilisant le <mode> pour délimiter les mots modifiés. Par défaut, les mots sont délimités par des espaces ; voir
--word-diff-regex
ci-dessous. Le <mode> vaut par défaut plain, et peut valoir :- color
-
Surligner les mots modifiés en n’utilisant que des couleurs. Implique
--color
. - plain
-
Afficher les mots comme
[-supprimé-]
et{+ajouté+}
. Ne pas tenter d’échapper ces délimiteurs s’ils apparaissent dans l’entrée, donc la sortie peut être ambigüe. - porcelain
-
Utiliser un format spécial ligne par ligne destiné à la consommation par script. Les séquences ajoutées/supprimées/non-modifiées sont affichées dans le format diff unifié habituel, commençant par un caractère
+
/-
/` ` en début de ligne et en étendant en fin de ligne. Les retours chariot dans l’entrée sont représentés par un tilde~
sur une ligne à part. - none
-
Désactiver à nouveau la diff par mots.
Notez qu’en dépit du nom du premier mode, la couleur est utilisée pour surligner les parties modifiées dans tous les modes, si activée.
- --word-diff-regex=<regex>
-
Utiliser <regex> pour décider ce qu’est un mot, au lieu de définir un mot comme une séquence continue de caractères non blancs. Implique aussi
--word-diff
à moins qu’elle ait déjà été spécifiée.Toutes correspondances de <regex> qui ne se chevauchent pas sont considérées comme des mots. Tout ce qui se situe entre ces correspondances est considéré comme de l’espace blanc et ignoré (!) lors du calcul de différences. Vous voudrez peut-être ajouter
|[^[:space:]]
à l’expression régulière pour être sûr qu’elle englobe tous les caractères non blancs. Une correspondance qui contient un retour à la ligne est tronquée silencieusement (!) au retour à la ligne.Par exemple,
--word-diff-regex=.
va traiter chaque caractère comme un mot et de ce fait présenter les différences caractère par caractère.La regex peut aussi être indiquée par un pilote de diff ou une option de configuration, voir gitattributes[5] ou git-config[1]. La ligne de commande a précédence sur le pilote de diff ou la configuration. Le pilote de diff a précédence sur l’option de configuration.
- --color-words[=<regex>]
-
Équivalent à
--word-diff=color
plus (si une regex a été spécifiée)--word-diff-regex=<regex>
. - --no-renames
-
Désactiver la détection de renommage, même si le fichier de configuration indique de le faire par défaut.
- --[no-]rename-empty
-
S’il faut utiliser les blobs vides comme source de renommage.
- --check
-
Avertir si les modifications introduisent des marqueurs de conflit ou des erreurs d’espaces. Les erreurs d’espaces sont définies par l’option de configuration
core.whitespace
. Par défaut, les espaces en fin de ligne (incluant les lignes ne contenant que des espaces) et le caractère espace suivi immédiatement par une tabulation lors d’une indentation initiale de ligne sont considérés comme des erreurs d’espace. Le code d’erreur de sortie est non nul en cas de problèmes trouvés. Non compatible avec--exit-code
. - --ws-error-highlight=<sorte>
-
Surligner les erreurs d’espace dans les lignes
context
(contexte),old
(ancien) etnew
(nouveau) du diff. Des valeurs multiples sont séparées par des virgules,none
réinitialise les valeurs précédentes,default
réinitialise la liste ànew
etall
est un raccourci pourold,new,context
. Quand cette option n’est pas fournie et que la variable de configurationdiff.wsErrorHighlight
n’est pas assignée, seules les erreurs d’espace dans les lignesnew
sont surlignées. Les erreurs d’espace sont colorées aveccolor.diff.whitespace
. - --full-index
-
Au lieu de montrer quelques-uns des premiers caractères, montrer les noms complets des objets blob des images pré et post sur la ligne d’index lors de la génération de la sortie au format patch.
- --binary
-
En plus de
--full-index
, afficher un diff binaire qui peut être appliqué avecgit-apply
. Implique--patch
. - --abbrev[=<n>]
-
Au lieu de montrer le nom de l’objet avec les 40 caractères hexadécimaux dans le format de diff brut et les lignes d’entête de l’arbre de diff, montrer le préfixe le plus court, d’une longueur d’au moins <n> chiffres hexadécimaux, qui renvoie à l’objet de manière unique. Dans le format de sortie de rustine de correctif,
--full-index
a une priorité plus élevée, c’est-à-dire si--full-index
est spécifié, les noms de blob complets seront affichés indépendamment de--abbrev
. Un nombre de chiffres différent de celui par défaut peut être spécifié avec--abbrev=<n>
. - -B[<n>][/<m>]
- --break-rewrites[=[<n>][/<m>]]
-
Casser les modifications de réécriture complète en paires de suppression et création. Cela sert deux objectifs :
Cela affecte la façon dont un changement qui équivaut à une réécriture totale d’un fichier apparaît non pas comme une série de suppressions et d’insertions mélangées avec quelques lignes qui (par hasard) correspondent entre les deux versions comme contexte, mais comme une simple suppression de tout ce qui est ancien suivi d’une simple insertion de tout ce qui est nouveau, et le nombre
m
contrôle cet aspect de l’option -B (par défaut 60 %).-B/70%
spécifie que moins de 30 % de l’original doit rester dans le résultat pour que Git le considère comme une réécriture totale (autrement, la rustine résultante sera une série de suppressions et d’insertions mélangées avec des lignes de contexte).Utilisé avec -M, un fichier complètement réécrit est aussi considéré comme la source d’un renommage (habituellement -M ne considère que les fichiers qui ont disparu comme source de renommage), et le nombre
n
contrôle le niveau de l’option -B (par défaut, 50 %).-B20%
signifie qu’une modification avec des additions et des suppressions représentant 20 % ou plus du contenu du fichier est considérée pour être utilisée comme une source possible pour un renommage en un autre fichier. - -M[<n>]
- --find-renames[=<n>]
-
Détecter les renommages. Si
n
est spécifié, c’est un seuil d’index de similarité (c-à-d la quantité d’addition/suppression comparé à la taille du fichier). Par exemple,-M90%
signifie que Git considérera un couple suppression/ajout comme renommage si plus de 90 % du fichier n’a pas changé. Sans le signe%
, le nombre doit être lu comme une fraction précédée du point décimal.-M5
devient 0,5, tout comme-M50%
. De même,-M05
est identique à-M5%
. Pour limiter la détection à des renommages exacts, utilisez-M100%
. L’index de similarité par défaut est50%
. - -C[<n>]
- --find-copies[=<n>]
-
Détecter les copies aussi bien que les renommages. Voir aussi
--find-copies-harder
. Sin
est spécifié, il a la même signification que pour-M<n>
. - --find-copies-harder
-
Pour des raisons de performance, par défaut, l’option
-C
trouve des copies seulement si le fichier original de la copie a été modifié dans le même ensemble de modifications. Ce drapeau fait inspecter à la commande les fichiers non modifiés comme candidats comme source de copie. C’est une opération très chère pour des projets importants, donc à utiliser avec précaution. Spécifier plusieurs fois l’option-C
a le même effet. - -D
- --irreversible-delete
-
Omettre la pré-image pour des suppressions, c-à-d n’afficher que l’entête mais pas la diff entre la pré-image et
/dev/null
. La rustine résultante n’est pas destinée à être appliquée avecpatch
ougit apply
; C’est seulement pour les personnes qui veulent juste se concentrer sur une revue des modifications. De plus, la sortie manque clairement d’assez d’information pour appliquer la rustine en inverse, même manuellement, d’où le nom de l’option.Lorsqu’utilisé conjointement avec
-B
, omettre aussi la pré-image dans la partie suppression d’une paire suppression/création. - -l<num>
-
Les options
-M
et-C
impliquent quelques étapes préliminaires qui peuvent détecter des sous-ensembles de renommages/copies à moindre coût, suivies d’une partie pour le reste qui compare toutes les destinations non appariées restantes à toutes les sources pertinentes. (Pour les renommages, seules les sources non appariées restantes sont pertinentes ; pour les copies, toutes les sources originales sont pertinentes). Pour N sources et destinations, cette vérification exhaustive est en O(N^2). Cette option empêche la partie exhaustive de la détection des renommages/copies de s’exécuter si le nombre de fichiers source/destination impliqués dépasse le nombre spécifié. La valeur par défaut est diff.renameLimit. Notez qu’une valeur de 0 est traitée comme illimitée. - --diff-filter=[(A|C|D|M|R|T|U|X|B)…[*]]
-
Sélectionner seulement les fichiers qui sont Ajoutés (
A
), Copiés (C
), supprimés (DeletedD
), Modifiés (M
), Renommés (R
), ont eu un changement de Type (T
) (c-à-d fichier normal, lien symbolique, sous-module …), sont non fusionnés (UnmergedU
), sont inconnus (UnknownX
) ou ont eu leur appairage cassé (BrokenB
). Toute combinaison de caractères de filtre (incluant aucun) peut être utilisée. Quand*
(Tout-ou-rien) est ajouté à la combinaison, tous les chemins sont sélectionnés s’il y a des fichiers qui correspondent aux autres critères dans la comparaison ; s’il n’y a aucun fichier qui correspond aux autres critères, rien n’est sélectionné.Aussi, ces lettres majuscules peuvent être spécifiées en minuscules pour exclure. Par exemple,
--diff-filter=ad
exclut les chemins ajoutés et supprimés.Notez que toutes les diffs ne peuvent pas présenter tous les types. Par exemple, les entrées copiées et renommées ne peuvent pas apparaître si la détection de ces types est désactivée.
- -S<chaîne>
-
Trouver des différences qui modifient le nombre d’occurrences de la chaîne spécifiée (par ex. addition/suppression) dans un fichier. Destiné à l’usage dans des scripts.
C’est utile lorsqu’on cherche un bloc exact de code (comme une struct), et qu’on veut connaître l’historique de ce bloc depuis son apparition : utiliser cette fonctionnalité itérativement pour fournir le bloc d’une pré-image à
-S
et continuer jusqu’à obtenir la toute première version du bloc.Les fichiers binaires sont aussi analysés.
- -G<regex>
-
Rechercher des différences dont le texte de rustine contient les lignes ajoutées/supprimées correspondant à <regex>.
Pour illustrer la différence entre
-S<regex> --pickaxe-regex
et-G<regex>
, considérons un commit contenant la diff suivante dans un même fichier :+ return frotz(nitfol, two->ptr, 1, 0); ... - hit = frotz(nitfol, mf2.ptr, 1, 0);
Alors que
git log -G"frotz\(nitfol"
affichera ce commit,git log -S"frotz\(nitfol" --pickaxe-regex
ne l’affichera pas (parce que le nombre d’occurrences de cette chaîne n’a pas changé).À moins que
--text
soit fourni, les rustines de fichiers binaires sans filtre textconv seront ignorées.Voir l’entrée pickaxe dans gitdiffcore[7] pour plus d’information.
- --find-object=<id-objet>
-
Rechercher les différences qui modifient le nombre d’occurrences de l’objet indiqué. Similaire à
-S
, juste que l’argument est différent en ce qu’elle ne cherche pas une chaîne particulière mais un identifiant d’objet particulier.L’objet peut être un commit de blob ou de sous-module. Cela implique l’option
-t
dansgit-log
pour trouver aussi des arbres. - --pickaxe-all
-
Quand
-S
ou-G
trouvent une modification, afficher toutes les modifications dans l’ensemble de modifications, pas seulement les fichiers qui contiennent la modification dans <chaîne>. - --pickaxe-regex
-
Traiter la <chaîne> fournie à
-S
comme une expression régulière POSIX étendue à faire correspondre. - -O<fichier-d-ordre>
-
Contrôler l’ordre dans lequel les fichiers apparaissent dans la sortie. Ceci passe outre la variable de configuration
diff.orderFile
(voir git-config[1]). Pour annulerdiff.orderFile
, utiliser-O/dev/null
.L’ordre en sortie est déterminé par l’ordre des motifs glob dans <fichier-d-ordre>. Tous les fichiers dont le nom de chemin correspond au premier motif sont affichés en premier, tous les fichiers dont le nom de chemin correspond au second motif (mais pas au premier) sont affichés ensuite, et ainsi de suite. Tous les fichiers dont les noms de chemin qui ne correspondent à aucun motif sont affichés en dernier, comme s’il y avait un motif ramasse-tout à la fin du fichier. Si de multiples noms de chemin ont le même rang (ils correspondent avec le même motif mais pas de motifs antérieurs), leur ordre relatif d’affichage est l’ordre normal.
<fichier-d-ordre> est analysé comme suit :
-
Les lignes blanches sont ignorées, de sorte qu’elles peuvent être utilisées comme séparateurs pour la lisibilité.
-
Les lignes commençant par un dièse ("
#
") sont ignorées, elles peuvent donc être utilisées comme commentaires. Ajoutez une barre oblique inverse ("\
") au début du motif s’il doit commencer par un dièse. -
Toutes les autres lignes contiennent un motif unique.
Les motifs ont la même syntaxe et sémantique que les motifs utilisés pour fnmatch(3) sans le drapeau FNM_PATHNAME, sauf qu’un nom de chemin correspond aussi à un motif si la suppression de n’importe quel nombre de composants finaux du nom de chemin correspond au motif. Par exemple, le motif "
foo*bar
" correspond à "fooasdfbar
" et "foo/bar/baz/asdf
" mais pas à "foobarx
". -
- --skip-to=<fichier>
- --rotate-to=<fichier>
-
Supprimer les noms des fichiers avant <fichier> dans la sortie (c’est-à-dire "skip to"), ou les déplacer à la fin de la sortie (c’est-à-dire "rotate to"). Ces options servent principalement lors de la commande
git difftool
, et peuvent ne pas être très utiles ailleurs. - -R
-
Échanger deux entrées ; c’est-à-dire afficher les différences depuis l’index ou avec un fichier sur disque avec le contenu de l’arbre.
- --relative[=<chemin>]
- --no-relative
-
Lorsque lancé depuis un sous-répertoire du projet, il peut lui être indiqué d’exclure les modifications hors du répertoire et d’afficher les noms de chemins relativement à lui avec cette option. Quand vous n’êtes pas dans un sous-répertoire (par ex. dans un dépôt nu), vous pouvez nommer quel sous-répertoire par rapport auquel afficher la sortie en fournissant un argument <chemin>. L’option
--no-relative
peut être utilisée pour annuler l’option de configurationdiff.relative
et l’option--relative
précédente. - -a
- --text
-
Traiter tous les fichiers comme texte.
- --ignore-cr-at-eol
-
Ignorer les retours chariot en fin de ligne lors de la comparaison.
- --ignore-space-at-eol
-
Ignorer les modifications d’espaces en fin de ligne.
- -b
- --ignore-space-change
-
Ignorer les modifications de nombre d’espaces. Cela ignore les espaces en fin de ligne et considère toutes les autres séquences d’un caractère blanc ou plus comme équivalentes.
- -w
- --ignore-all-space
-
Ignorer les espaces lors de la comparaison de lignes. Ceci ignore les différences même si une ligne a des espaces quand l’autre n’en a aucun.
- --ignore-blank-lines
-
Ignorer les modifications dont les lignes sont blanches.
- -I<regex>
- --ignore-matching-lines=<regex>
-
Ignorer les modifications dont toutes les lignes correspondent à <regex>. Cette option peut être spécifiée plusieurs fois.
- --inter-hunk-context=<lignes>
-
Afficher le contexte entre des sections de diff, jusqu’au nombre spécifié de lignes, fusionnant de ce fait les sections qui sont proches. Par défaut,
diff.interHunkContext
ou 0 si l’option de configuration n’est pas configurée. - -W
- --function-context
-
Afficher l’ensemble de la fonction comme lignes de contexte pour chaque modification. Les noms de fonction sont déterminés de la même manière que git diff génère sur les en-têtes de sections de rustines(voir Définir un en-tête personnalisé dans gitattributes[5]).
- --exit-code
-
Faire sortir le programme avec un code similaire à diff(1). Autrement dit, il sort avec 1 s’il y avait des différences et 0 signifie aucune différence.
- --quiet
-
Désactiver tous les résultats du programme. Implies
--exit-code
. Désactive l’exécution de l’assistant de diff externe dont le code de sortie n’est pas fiable, c’est-à-dire que leur option de configuration respectivediff.trustExitCode ' ou `diff.<pilote>.trustExitCode
ou la variable d’environnement GIT_EXTERNAL_DIFF_TRUST_EXIT_CODE sont àfalse
. - --ext-diff
-
Permettre l’exécution d’un assistant externe de différence. Si vous définissez un pilote externe de différence avec gitattributes[5], vous avez besoin d’utiliser cette option avec git-log[1] et compagnie.
- --no-ext-diff
-
Désactiver les pilotes de diff externes.
- --textconv
- --no-textconv
-
Permettre (ou désactiver) le lancement des filtres externes de conversion en texte lors de la comparaison de fichiers binaires. Voir gitattributes[5] pour plus de détails. Comme les filtres textconv sont typiquement des conversions à sens unique, la diff résultante est adaptée à la consommation humaine, mais ne peut pas être appliquée. Pour cette raison, les filtres textconv sont activés par défaut seulement pour git-diff[1] et git-log[1], mais pas pour git-format-patch[1] ou les commandes de plomberie de diff.
- --ignore-submodules[=<quand>]
-
Ignorer les modifications à des sous-modules lors de la génération du diff. <quand> peut valoir "none" (aucun), "untracked" (non-suivi), "dirty" (sale) ou "all" (tout) qui est la valeur par défaut. L’utilisation de "none" va considérer comme modifiés les sous-modules quand ils contiennent soit des fichiers non-suivis ou modifiés, ou si sa HEAD diffère du commit enregistré dans le super-projet, et peut être utilisé pour passer outre tout réglage de l’option ignore dans git-config[1] ou gitmodules[5]. Quand "untracked" est utilisé, les sous-modules ne sont pas considérés sales quand ils ne contiennent que du contenu non suivi (mais ils sont quand même scannés pour trouver du contenu modifié). L’utilisation de "dirty" ignore toutes les modifications à l’arbre de travail des sous-modules ; seules les modifications aux commits stockés dans le super-projet sont affichées (c’était le comportement jusqu’à 1.7.0). La valeur "all" cache toutes les modifications des sous-modules.
- --src-prefix=<préfixe>
-
Afficher le préfixe de source fourni au lieu de "a/".
- --dst-prefix=<préfixe>
-
Afficher le préfixe de destination fourni au lieu de "b/".
- --no-prefix
-
N’afficher aucun préfixe ni de source, ni de destination.
- --default-prefix
-
Utiliser les préfixes source et destination par défaut ("a/" et "b/"). Cela surcharge les variables de configuration telles que configuration telle que
diff.noprefix
,diff.srcPrefix
,diff.dstPrefix
, etdiff.mnemonicPrefix
(voirgit-config
(1)). - --line-prefix=<préfixe>
-
Préfixer avec une chaîne additionnelle chaque ligne de la sortie.
- --ita-invisible-in-index
-
Par défaut, une entrée ajoutée par "git add -N" apparaît comme un fichier vide existant dans "git diff" et un nouveau fichier dans "git diff --cached". Cette option fait apparaître l’entrée comme un fichier nouveau dans "git diff" et non existant dans "git diff --cached". Cette option peut être inversée avec
--ita-visible-in-index
. Les deux options sont expérimentales et peuvent être retirées dans le futur.
Pour une explication plus détaillée sur ces options communes, voir aussi gitdiffcore[7].
- -1 --base
- -2 --ours
- -3 --theirs
-
Comparer l’arbre de travail avec la version de « base » (étape #1), « notre branche » (étape #2) ou « leur branche » (étape #3). L’index contient ces étapes seulement pour les entrées non-fusionnées, c’est-à-dire lors de la résolution de conflits. Voir la section « Fusion à 3 points » de git-read-tree[1] pour de plus amples informations.
- -0
-
Omettre la sortie de diff pour les entrées non-fusionnées et affiche juste « Non fusionné ». Ne peut être utilisé que lors de comparaison de l’arbre de travail avec l’index.
- <chemin>…
-
Les paramètres <chemin>, quand spécifiés, sont utilisés pour limiter la différence aux chemins indiqués (vous pouvez indiquer des noms de répertoire et visualiser les différences pour tous les fichiers qu’ils contiennent).
Format brut de sortie
Les formats bruts de sortie de "git-diff-index", "git-diff-tree", "git-diff-files" et "git diff --raw" sont très similaires.
Ces commandes comparent toutes deux ensembles de choses ; ce qui est comparé varie :
- git-diff-index <arbre-esque>
-
compare l'<arbre-esque> et les fichiers du système de fichiers.
- git-diff-index --cached <arbre-esque>
-
compare l'<arbre-esque> et l’index.
- git-diff-tree [-r] <arbre-esque-1> <arbre-esque-2> [<motif>…]
-
Compare les arbres nommés par les deux arguments.
- git-diff-files [<motif>…]
-
compare l’index et les fichiers sur le système de fichier.
La commande "git-diff-tree" débute sa sortie par l’empreinte de ce qui est comparé. Ensuite, toutes les commandes affichent une ligne par fichier modifié.
une ligne affichée est formatée de la manière suivante :
édition en place :100644 100644 bcd1234 0123456 M fichier0 copie édition :100644 100644 abcd123 1234567 C68 fichier1 fichier2 édition renommage :100644 100644 abcd123 1234567 R86 fichier1 fichier3 création :000000 100644 0000000 1234567 A fichier4 suppression :100644 000000 1234567 0000000 D fichier5 non fusionnné :000000 000000 0000000 0000000 U fichier6
C’est-à-dire, de gauche à droite :
-
deux points.
-
le mode pour "src" ; 000000 si c’est une création ou non fusionné.
-
un espace.
-
mode pour "dst" ; 000000 si suppression ou non-fusionné.
-
un espace.
-
sha1 de "src", 0{40} si création ou non fusionné.
-
un espace.
-
sha1 de "dst", 0{40} si suppression, non fusionné ou "arbre de travail désynchronisé par rapport à l’index".
-
un espace.
-
status, suivi optionnellement d’un nombre score.
-
une tabulation ou un caractère NUL si l’option
-z
est utilisée. -
chemin pour "src"
-
une tabulation ou un caractère NUL si l’option
-z
est utilisée ; n’existe que pour C ou R. -
chemin pour "dst" ; n’existe que pour C ou R.
-
un caractère LF ou NUL si l’option
-z
est utilisée, pour terminer l’enregistrement.
Les lettres de statut possibles sont :
-
A : addition d’un fichier
-
C : copie d’un fichier en un autre
-
D : suppression (deletion) d’un fichier
-
M : modification de contenu ou du mode d’un fichier
-
R : renommage d’un fichier
-
T : modification du type d’un fichier (fichier régulier, lien symbolique ou sous-module)
-
U : le fichier est non-fusionné (unmerged) (vous devez finir la fusion avant de le valider)
-
X : type de modification "inconnue" (probablement un bug, veuillez le signaler)
Les lettres de statut C et R sont toujours suivies d’un score (indiquant le pourcentage de similarité entre la source et la cible du déplacement ou de la copie). La lettre de statut M peut être suivie d’un score (indiquant le pourcentage de dissimilarité) pour une réécriture de fichier.
Le sha1 de "dst" est tout à zéro si le fichier sur le système de fichiers est désynchronisé par rapport à l’index.
Exemple :
:100644 100644 5be4a4a 0000000 M fichier.c
Sans l’option -z
, les noms de chemin avec des caractères « inhabituels » sont cités comme expliqué pour la variable de configuration core.quotePath
(voir git-config[1]). Lors de l’utilisation de -z
le fichier est affiché verbatim et la ligne est terminée par un octet NUL.
format diff pour les fusions
"git-diff-tree", "git-diff-files" et "git-diff --raw" peuvent prendre une option -c
ou --cc
pour générer une sortie diff pour les commits de fusion. La sortie diffère du format décrit ci-dessus sur les points suivants :
-
il y a un caractère deux points pour chaque parent
-
il y a plus de modes "src" et de sha1 "src"
-
les statut est la concaténation des caractères de statut de chaque parent
-
pas de nombre optionnel de "score"
-
chemin(s) d’accès du fichier séparé(s) par des tabulations
Pour -c
et --cc
, seule la destination ou le chemin final est affiché même si le fichier a été renommé d’un côté ou de l’autre de l’historique. Avec --combined-all-paths
, le nom du chemin dans chaque parent est affiché suivi du nom du chemin dans le commit de fusion.
Exemples pour -c
et --cc
sans --combined-all-paths
:
::100644 100644 100644 fabadb8 cc95eb0 4866510 MM desc.c ::100755 100755 100755 52b7a2d 6d1ac04 d2ac7d7 RM bar.sh ::100644 100644 100644 e07d6c5 9042e82 ee91881 RR phooey.c
Exemples où --combined-all-paths
a été ajouté à -c
ou --cc
:
::100644 100644 100644 fabadb8 cc95eb0 4866510 MM desc.c desc.c desc.c ::100755 100755 100755 52b7a2d 6d1ac04 d2ac7d7 RM foo.sh bar.sh bar.sh ::100644 100644 100644 e07d6c5 9042e82 ee91881 RR fooey.c fuey.c phooey.c
Notez que le diff combiné ne liste que les fichiers qui ont été modifiés depuis tous leurs parents.
Génération du texte de rustine avec -p
Exécuter git-diff[1], git-log[1], git-show[1], git-diff-index[1], git-diff-tree[1] ou git-diff-files[1] avec l’option -p
produit le texte de rustine. Vous pouvez personnaliser la création du texte de rustine via les variables d’environnement GIT_EXTERNAL_DIFF
et GIT_DIFF_OPTS
(voir git[1]), et l’attribut diff
(voir gitattributes[5]).
L’option produit quelque chose légèrement différent du format diff traditionnel :
-
Il est précédé d’un entête "git diff" qui ressemble à ceci :
diff --git a/fichier1 b/fichier2
les noms de fichiers sous
a/
etb/
sont identiques à moins qu’il y ait eu un renommage ou une copie, même pour un création ou une suppression,/dev/null
n’est pas utilisé à la place des noms de fichiera/
ou`b/`.Quand un renommage ou un copie est décrit,
fichier1
etfichier2
indiquent les noms du fichier source et du fichier cible, respectivement. -
Suivent un ligne ou plus d’entête étendu :
old mode <mode> new mode <mode> deleted file mode <mode> new file mode <mode> copy from <chemin> copy to <chemin> rename from <chemin> rename to <chemin> similarity index <nombre> dissimilarity index <nombre> index <empreinte>..<empreinte> <mode>
Les modes de fichier sont affichés comme des nombres à 6 chiffres en octal incluant le type de fichier et les bits de permission.
Les noms de chemin dans les entêtes étendus n’incluent pas les préfixes
a/
etb/
.L’index de similarité et le pourcentage de lignes inchangées et l’index de dissimilarité est le pourcentage de lignes changées. Il est arrondi à l’entier inférieur, suivi du signe pourcent. Une valeur d’index de similarité à 100 % correspond donc à deux fichiers identiques, tandis qu’un index de dissimilarité de 100 % signifie qu’aucune ligne de l’ancien fichier ne se retrouve dans le nouveau fichier.
La ligne d’index inclut les noms des objets blob avant et après la modification. Le <mode> est inclus si le mode du fichier n’est pas modifié ; sinon, des lignes séparées indiquent l’ancien et le nouveau mode.
-
Les noms de chemin avec des caractères « inhabituels » sont cités comme expliqué pour la variable de configuration
core.quotePath
(voir git-config[1]). -
Tous les fichiers
fichier1
de la sortie font référence à des fichiers avant la validation, et tous les fichiersfichier2
font référence aux fichiers après la validation. Il est incorrect d’appliquer chaque modification à chaque fichier séquentiellement. Par exemple, cette rustine échange a et b :diff --git a/a b/b rename from a rename to b diff --git a/b b/a rename from b rename to a
-
Les en-têtes de section mentionnent le nom de la fonction à laquelle la section s’applique. Voir "Définition d’un entête de section personnalisé" dans gitattributes[5] pour des détails sur la façon d’adapter cela à des langages spécifiques.
Format de diff combiné
Toute commande générant un diff accepte l’option -c
ou --cc
pour produire un diff combiné lors de l’affichage d’une fusion. C’est le format par défaut pour afficher les fusions avec git-diff[1] ou git-show[1]. Notez aussi que vous pouvez ajouter l’option adaptée --diff-merges
à toutes ces commandes pour forcer la génération des diffs dans un format spécifique.
Un format de diff combiné ressemble à ceci :
diff --combined describe.c index fabadb8,cc95eb0..4866510 --- a/describe.c +++ b/describe.c @@@ -98,20 -98,12 +98,20 @@@ return (a_date > b_date) ? -1 : (a_date == b_date) ? 0 : 1; } - static void describe(char *arg) -static void describe(struct commit *cmit, int last_one) ++static void describe(char *arg, int last_one) { + unsigned char sha1[20]; + struct commit *cmit; struct commit_list *list; static int initialized = 0; struct commit_name *n; + if (get_sha1(arg, sha1) < 0) + usage(describe_usage); + cmit = lookup_commit_reference(sha1); + if (!cmit) + usage(describe_usage); + if (!initialized) { initialized = 1; for_each_ref(get_name);
-
Il est précédé d’un entête "git diff", qui ressemble à ceci (quand l’option
-c
est utilisée) :diff --combined file
ou à ceci (lorsque l’option
--cc
est utilisée) :diff --cc file
-
Il est suivi par une ligne d’entête étendu ou plus (cet exemple montre une fusion avec deux parents) :
index <empreinte>,<empreinte>..<empreinte> mode <mode>,<mode>..<mode> new file mode <mode> deleted file mode <mode>,<mode>
La ligne
mode <mode>,<mode>..<mode>
n’apparaît que si au moins un des modes est différent du reste. Les entêtes étendus avec l’information à propos des déplacements détectés de contenu (détection de renommages et de copies) sont conçus pour fonctionner avec le diff de deux <arbre-esques> et ne sont pas utilisés dans le format de diff combiné. -
Il est suivi par un entête de deux lignes fichier-source/fichier-cible :
--- a/fichier +++ b/fichier
Similaire à l’entête à deux lignes pour le format diff unifié traditionnel,
/dev/null
est utilisé pour indiquer un fichier créé ou supprimé.Cependant, si l’option --combined-all-paths est fournie, au lieu des deux lignes de fichier-source/fichier-cible, vous obtenez un en-tête de N+1 lignes de fichier-source/fichier-cible, où N est le nombre de parents dans le commit de fusion :
--- a/fichier --- a/fichier --- a/fichier +++ b/fichier
Ce format étendu peut être utile si la détection de renommage ou de copie est active, pour vous permettre de voir le nom original du fichier dans différents parents.
-
Le format d’entête de section est modifié pour empêcher l’utilisation accidentelle avec
patch -p1
. Le format de diff combiné a été créé pour les revues des modifications de commits de fusions, et n’était pas destiné à être appliqué. La modification est similaire à la modification dans l’entête étendu d’index :@@@ <intervalle-de-fichier-source> <intervalle-de-fichier-source> <intervalle-de-fichier-cible> @@@
Il y a (nombre de parents + 1) caractères
@
dans l’entête de section pour le format de diff combiné.
À la différence du format diff unifié traditionnel qui montre deux fichiers A et B avec une seule colonne qui a un préfixe -
(moins — apparaît dans A mais supprimé dans B), +
(plus — manquant dans A mais ajouté dans B), ou " "
(espace — non modifié), ce format compare un fichier ou plus fichier1, fichier2,… avec un fichier X, et affiche comment X diffère de chaque fichierN. Une colonne pour chaque fichierN est insérée dans la sortie pour montrer comment la ligne de X est différente de la ligne correspondante de celui-ci.
Un caractère -
dans la colonne N signifie que la ligne apparaît dans fichierN mais pas dans le résultat. Un caractère +
dans la colonne N signifie que la ligne apparaît dans le résultat, et fichierN ne l’a pas (en d’autres termes, la ligne a été ajoutée du point de vue de ce parent).
Dans l’exemple de sortie ci-dessus, la signature de la fonction a été changée depuis les deux fichiers (d’où les deux suppressions -
depuis fichier1 et fichier2, plus ++
pour signifier qu’une ligne qui a été ajoutée n’apparaît ni dans fichier1 ni dans fichier2). De plus, huit autres lignes sont identiques depuis fichier1 mais n’apparaissent pas dans fichier2 (et sont donc préfixées par +
).
Quand affiché par git diff-tree -c
, les parents du commit de fusion sont comparés avec le résultat de fusion (c-à-d fichier1..fichierN sont les parents) ; Quand affiché par git diff-files -c
, les deux parents de fusion non résolue sont comparés avec le fichier dans l’arbre de travail (c-à-d fichier1 est stage 2, « notre version », fichier2 est stage 3, « leur version »).
autres formats de diff
L’option --summary
décrit les fichiers nouvellement additionnés, supprimés, renommés et copiés. L’option --stat
ajoute un graphe diffstat(1) à la sortie. Ces options peuvent être combinées avec d’autres options, telles que -p
et sont destinées à une consommation humaine.
Lors de l’affichage d’une modification qui comprend un renommage ou une copie, la sortie de --stat
formate de manière compacte les noms de chemins en combinant les préfixes et suffixes communs des noms de chemins. Par exemple, une modification qui déplace arch/i386/Makefile
vers arch/x86/Makefile
en modifiant 4 lignes seront affichées comme ceci :
arch/{i386 => x86}/Makefile | 4 +--
L’option --numstat
donne l’information diffstat(1) mais est organisée pour un meilleur traitement automatique. Une entrée dans --numstat
ressemble à ceci :
1 2 README 3 1 arch/{i386 => x86}/Makefile
Soit, de gauche à droite :
-
le nombre de lignes ajoutées ;
-
une tabulation ;
-
le nombre de lignes supprimées ;
-
une tabulation ;
-
nom de chemin (avec potentiellement une information de renommage/copie) ;
-
une retour à la ligne.
Quand l’option de sortie -z
est active, la sortie est formatée comme ceci :
1 2 README NUL 3 1 NUL arch/i386/Makefile NUL arch/x86/Makefile NUL
Soit :
-
le nombre de lignes ajoutées ;
-
une tabulation ;
-
le nombre de lignes supprimées ;
-
une tabulation ;
-
un caractère NUL (n’existe que si renommé/copié) ;
-
le nom de chemin dans preimage ;
-
un caractère NUL (n’existe que si renommé/copié) ;
-
le nom de chemin dans postimage (n’existe que si renommé/copié) ;
-
un caractère NUL.
Le caractère NUL
supplémentaire avant le chemin de préimage dans le cas de renommage permet aux scripts qui lisent la sortie de détecter si l’enregistrement actuellement lu est un enregistrement de chemin unique ou un enregistrement de renommage/copie sans avoir besoin de lire plus loin. Après lecture des lignes ajoutées et supprimées, une lecture jusqu’au caractère NUL
fournit le nom de chemin, mais si c’est NUL
, l’enregistrement fournit deux chemins.
EXEMPLES
- Différents moyens de vérifier votre arbre de travail
-
$ git diff (1) $ git diff --cached (2) $ git diff HEAD (3) $ git diff AUTO_MERGE (4)
-
Modifications dans l’arbre de travail pas encore indexées pour la prochaine validation.
-
Modifications entre l’index et votre dernier commit ; ce que vous valideriez si vous lanciez
git commit
sans l’option-a
. -
Modifications dans l’arbre de travail depuis votre dernier commit ; ce que vous valideriez si vous lanciez
git commit -a
-
Changements dans l’arbre de travail que vous avez fait pour résoudre les conflits textuels jusqu’à présent.
-
- Comparaison de deux commits arbitraires
-
$ git diff test (1) $ git diff HEAD -- ./test (2) $ git diff HEAD^ HEAD (3)
-
Au lieu d’utiliser le sommet de la branche actuelle, compare avec le sommet de la branche « test ».
-
Au lieu de comparer avec le sommet de la branche « test », compare avec le sommet de la branche actuelle, mais limite la comparaison au fichier « test ».
-
Compare la version précédant le dernier commit et le dernier commit.
-
- Comparaison de branches
-
$ git diff sujet master (1) $ git diff sujet..master (2) $ git diff sujet...master (3)
-
Modifications entre les sommets des branches sujet et master.
-
Identique à ci-dessus.
-
Modifications présentes sur la branche master depuis que la branche sujet en a divergé.
-
- Limitation de la sortie du diff
-
$ git diff --diff-filter=MRC (1) $ git diff --name-status (2) $ git diff arch/i386 include/asm-i386 (3)
-
Ne montre que les modifications, les renommages et les copies, mais pas les additions ou les suppressions.
-
Ne montre que les noms et la nature de la modification, mais pas la sortie de diff.
-
Limite la sortie de diff aux sous-arbres indiqués.
-
- Bricoler la sortie diff
-
$ git diff --find-copies-harder -B -C (1) $ git diff -R (2)
-
Dépense des cycles supplémentaires de CPU pour trouver les renommages, les copies ou les réécritures complètes (très cher).
-
Affiche les diff inversés.
-
CONFIGURATION
Warning
|
Missing See original version for this content. |
Warning
|
Missing See original version for this content. |
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 .