Français â–Ÿ Topics â–Ÿ Latest version â–Ÿ git-diff last updated in 2.51.0

NOM

git-diff - Affiche les modifications entre les commits, un commit et l’arbre de travail, etc

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> (HEAD) le plus rĂ©cent, 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^! et git 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].

git diff [<options>] <blob> <blob>

Cette forme sert à visualiser la différence entre les contenus bruts de deux objets blob.

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 commence par <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Ă©glant diff.statNameWidth=<largeur>. La largeur de la partie du graphe peut ĂȘtre limitĂ©e en utilisant --stat-graph-width=<largeur-de-graphe> ou en rĂ©glant diff.statGraphWidth=<largeur-de-graphe>. L’utilisation de --stat ou --stat-graph-width affecte toutes les commandes qui gĂ©nĂšrent un graphique de stat, tandis que rĂ©gler diff.statNameWidth or diff.statGraphWidth n’affecte pas git 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 de 0 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 [<param>,...]
--dirstat[=<param>,...]

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 configuration diff.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 comportement changes, 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Ăštre noncumulative.

<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[=<param>,...]

Synonyme de --dirstat=files,<param>,....

--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 fait summary 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Ă©faut diff.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 ĂȘtre always, never ou auto. Ceci peut ĂȘtre changĂ© par les rĂ©glages de configuration color.ui et color.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=<mode>,...

Ceci configure comment les espaces sont ignorĂ©s lors de la dĂ©tection de dĂ©placement par --color-moved. Le rĂ©glage de configuration diff.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>]

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) et new (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 et all est un raccourci pour old,new,context. Quand cette option n’est pas fournie et que la variable de configuration diff.wsErrorHighlight n’est pas assignĂ©e, seules les erreurs d’espace dans les lignes new sont surlignĂ©es. Les erreurs d’espace sont colorĂ©es avec color.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Ă© avec git-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 est 50%.

-C[<n>]
--find-copies[=<n>]

DĂ©tecter les copies aussi bien que les renommages. Voir aussi --find-copies-harder. Si <n> 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 avec patch ou git 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 (Deleted D), 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 (Unmerged U), sont inconnus (Unknown X) ou ont eu leur appairage cassĂ© (Broken B). 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 dans git-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 annuler diff.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 configuration diff.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 respective diff.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[=(none|untracked|dirty|all)]

Ignorer les modifications dans des sous-modules lors de la gĂ©nĂ©ration du diff. all (tout) est la valeur par dĂ©faut. L’utilisation de none va considĂ©rer les sous-modules comme modifiĂ©s quand ils contiennent soit des fichiers non-suivis ou modifiĂ©s, ou si leur 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’à v1.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, et diff.mnemonicPrefix (voir git-config[1]).

--line-prefix=<préfixe>

Ajouter le <préfixe> additionnel à 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 à

  • la version "base" (Ă©tape #1) en utilisant -1 ou --base,

  • "notre branche" (Ă©tape #2) en utilisant -2 ou --ours, ou

  • "leur branche" (Ă©tape #3) en utilisant -3 ou --theirs.

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 :

  1. deux points.

  2. le mode pour "src" ; 000000 si c’est une crĂ©ation ou non fusionnĂ©.

  3. un espace.

  4. mode pour "dst" ; 000000 si suppression ou non-fusionnĂ©.

  5. un espace.

  6. sha1 de "src", 0{40} si création ou non fusionné.

  7. un espace.

  8. sha1 de "dst", 0{40} si suppression, non fusionnĂ© ou "arbre de travail dĂ©synchronisĂ© par rapport Ă  l’index".

  9. un espace.

  10. status, suivi optionnellement d’un nombre score.

  11. une tabulation ou un caractĂšre NUL si l’option -z est utilisĂ©e.

  12. chemin pour "src"

  13. une tabulation ou un caractĂšre NUL si l’option -z est utilisĂ©e ; n’existe que pour C ou R.

  14. chemin pour "dst" ; n’existe que pour C ou R.

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

  1. il y a un caractĂšre deux points pour chaque parent

  2. il y a plus de modes "src" et de sha1 "src"

  3. les statut est la concaténation des caractÚres de statut de chaque parent

  4. pas de nombre optionnel de "score"

  5. 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]).

Ce que l’option -p produit est lĂ©gĂšrement diffĂ©rent du format diff traditionnel :

  1. 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/ et b/ 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 fichier a/ ou`b/`.

    Quand un renommage ou un copie est décrit, fichier1 et fichier2 indiquent les noms du fichier source et du fichier cible, respectivement.

  2. 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 <mode> 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/ et b/.

    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.

  3. 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]).

  4. Tous les fichiers fichier1 de la sortie font rĂ©fĂ©rence Ă  des fichiers avant la validation, et tous les fichiers fichier2 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
  5. 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);
  1. 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
  2. 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Ă©.

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

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

  1. le nombre de lignes ajoutĂ©es ;

  2. une tabulation ;

  3. le nombre de lignes supprimĂ©es ;

  4. une tabulation ;

  5. nom de chemin (avec potentiellement une information de renommage/copie) ;

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

  1. le nombre de lignes ajoutĂ©es ;

  2. une tabulation ;

  3. le nombre de lignes supprimĂ©es ;

  4. une tabulation ;

  5. un caractĂšre NUL (n’existe que si renommĂ©/copiĂ©) ;

  6. le nom de chemin dans preimage ;

  7. un caractĂšre NUL (n’existe que si renommĂ©/copiĂ©) ;

  8. le nom de chemin dans postimage (n’existe que si renommĂ©/copiĂ©) ;

  9. 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)
  1. Modifications dans l’arbre de travail pas encore indexĂ©es pour la prochaine validation.

  2. Modifications entre l’index et votre dernier commit ; ce que vous valideriez si vous lanciez git commit sans l’option -a.

  3. Modifications dans l’arbre de travail depuis votre dernier commit ; ce que vous valideriez si vous lanciez git commit -a

  4. 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)
  1. Au lieu d’utiliser le sommet de la branche actuelle, compare avec le sommet de la branche « test Â».

  2. 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 Â».

  3. 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)
  1. Modifications entre les sommets des branches sujet et master.

  2. Identique Ă  ci-dessus.

  3. 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)
  1. Ne montre que les modifications, les renommages et les copies, mais pas les additions ou les suppressions.

  2. Ne montre que les noms et la nature de la modification, mais pas la sortie de diff.

  3. 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)
  1. Dépense des cycles supplémentaires de CPU pour trouver les renommages, les copies ou les réécritures complÚtes (trÚs cher).

  2. Affiche les diff inversés.

CONFIGURATION

Tout ce qui se trouve en dessous de cette ligne dans cette section est inclus de maniĂšre sĂ©lective Ă  partir de la documentation git-config[1]. Le contenu est le mĂȘme que celui qui s’y trouve :

Warning

Missing fr/config/diff.adoc

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 .

scroll-to-top