git-diff-index - En ligne dans le Cloud

PROGRAMME:

Nom

git-diff-index - Compare un arbre à l'arbre ou à l'index de travail

SYNOPSIS

jet indice de différence [-m] [--caché] [ ] [ ...]

DESCRIPTION

Compare le contenu et le mode des blobs trouvés dans un objet arbre avec le
fichiers suivis dans l'arbre de travail, ou avec les chemins correspondants dans l'index. Lorsque
arguments sont présents, ne compare que les chemins correspondant à ces modèles. Sinon tout
les fichiers suivis sont comparés.

OPTIONS

-p, -u, --patch
Générer un patch (voir la section sur la génération de patchs).

-s, --pas de patch
Supprimer la sortie diff. Utile pour les commandes comme git show qui affichent le patch par
par défaut, ou pour annuler l'effet de --patch.

-U , --unifié=
Générer des différences avec lignes de contexte au lieu des trois habituelles. Implique -p.

--cru
Générez le diff au format brut. C'est la valeur par défaut.

--patch-avec-brut
Synonyme de -p --raw.

--minimal
Passez plus de temps pour vous assurer que la plus petite différence possible est produite.

--la patience
Générez un diff en utilisant l'algorithme "patience diff".

--histogramme
Générez un diff en utilisant l'algorithme "histogram diff".

--diff-algorithm={patience|minimal|histogramme|myers}
Choisissez un algorithme de différence. Les variantes sont les suivantes :

par défaut, myers
L'algorithme de base de diff gourmand. Actuellement, c'est la valeur par défaut.

minimal
Passez plus de temps pour vous assurer que la plus petite différence possible est produite.

patience
Utilisez l'algorithme "patience diff" lors de la génération de patchs.

histogramme
Cet algorithme étend l'algorithme de patience pour « prendre en charge les
éléments".

Par exemple, si vous avez configuré la variable diff.algorithm sur une valeur différente de celle par défaut et
voulez utiliser celui par défaut, alors vous devez utiliser l'option --diff-algorithm=default.

--stat[= [, [, ]]]
Générez un diffstat. Par défaut, autant d'espace que nécessaire sera utilisé pour le
partie nom de fichier, et le reste pour la partie graphique. La largeur maximale par défaut est le terminal
largeur, ou 80 colonnes s'il n'est pas connecté à un terminal, et peut être remplacé par .
La largeur de la partie nom de fichier peut être limitée en donnant une autre largeur
après une virgule. La largeur de la partie graphique peut être limitée en utilisant
--stat-graph-width= (affecte toutes les commandes générant un graphique de statistiques) ou par
paramètre diff.statGraphWidth= (n'affecte pas git format-patch). En donnant un
troisième paramètre , vous pouvez limiter la sortie au premier lignes, suivi
par ... s'il y en a plus.

Ces paramètres peuvent également être définis individuellement avec --stat-width= ,
--stat-name-width= et --stat-count= .

--numstat
Similaire à --stat, mais affiche le nombre de lignes ajoutées et supprimées en notation décimale et
chemin d'accès sans abréviation, pour le rendre plus convivial pour la machine. Pour les fichiers binaires,
sort deux - au lieu de dire 0 0.

--shortstat
Afficher uniquement la dernière ligne du format --stat contenant le nombre total de modifications
fichiers, ainsi que le nombre de lignes ajoutées et supprimées.

--dirstat[= ]
Affiche la distribution de la quantité relative de modifications pour chaque sous-répertoire. Les
le comportement de --dirstat peut être personnalisé en lui passant une liste séparée par des virgules de
paramètres. Les valeurs par défaut sont contrôlées par la variable de configuration diff.dirstat
(voir git-config(1)). Les paramètres suivants sont disponibles :

change
Calculez les nombres de dirstat en comptant les lignes qui ont été supprimées du
source ou ajouté à la destination. Cela ignore la quantité de code pur
mouvements dans un fichier. En d'autres termes, la réorganisation des lignes dans un fichier n'est pas
compté autant que les autres changements. C'est le comportement par défaut lorsqu'aucun paramètre
est donné.

lignes
Calculez les nombres de dirstat en effectuant l'analyse diff régulière basée sur la ligne, et
additionnant le nombre de lignes supprimées/ajoutées. (Pour les fichiers binaires, comptez les morceaux de 64 octets
à la place, puisque les fichiers binaires n'ont pas de concept naturel de lignes). C'est un plus
cher --dirstat comportement que les changements de comportement, mais cela compte
réarrangé les lignes dans un fichier autant que d'autres changements. La sortie résultante est
cohérent avec ce que vous obtenez des autres options --*stat.

fichiers
Calculez les numéros de dirstat en comptant le nombre de fichiers modifiés. Chacun a changé
le fichier compte également dans l'analyse dirstat. C'est le calcul le moins cher
--dirstat comportement, car il n'a pas du tout besoin de regarder le contenu du fichier.

accumulé
Comptez également les modifications dans un répertoire enfant pour le répertoire parent. Noter que
lors de l'utilisation du cumul, la somme des pourcentages rapportés peut dépasser 100 %. Les
le comportement par défaut (non cumulatif) peut être spécifié avec le non cumulatif
paramètre.


Un paramètre entier spécifie un pourcentage de coupure (3 % par défaut). Annuaires
contribuant moins que ce pourcentage des changements ne sont pas affichés dans la sortie.

Exemple : ce qui suit comptera les fichiers modifiés, tout en ignorant les répertoires avec moins
plus de 10 % du nombre total de fichiers modifiés et l'accumulation du nombre de répertoires enfants
dans les répertoires parents : --dirstat=files,10,cumulative.

--sommaire
Générer un résumé condensé des informations d'en-tête étendues telles que les créations, les renommages
et les changements de mode.

--patch-avec-stat
Synonyme de -p --stat.

-z
Lorsque --raw, --numstat, --name-only ou --name-status a été donné, ne pas munge
chemins d'accès et utilisez les NUL comme terminateurs de champ de sortie.

Sans cette option, chaque sortie de chemin aura TAB, LF, des guillemets doubles et
caractères de barre oblique inverse remplacés par \t, \n, \", et \\, respectivement, et le nom de chemin
seront entourés de guillemets doubles si l'un de ces remplacements a eu lieu.

--nom-seulement
Afficher uniquement les noms des fichiers modifiés.

--nom-statut
Afficher uniquement les noms et l'état des fichiers modifiés. Voir la description du --diff-filter
option sur la signification des lettres d'état.

--sous-module[= ]
Spécifiez comment les différences dans les sous-modules sont affichées. Lorsque --submodule ou --submodule=log
est donné, le enregistrer format est utilisé. Ce format répertorie les commits dans la plage comme git-
sous-module(1) résumé fait. En omettant l'option --submodule ou en spécifiant
--submodule=short, utilise le court format. Ce format n'affiche que les noms des
commits au début et à la fin de la plage. Peut être modifié via le diff.submodule
variable de configuration.

--couleur[= ]
Afficher les diff. --color (c'est-à-dire sans =) est identique à --color=always.
peut être toujours, jamais ou automatique.

--sans couleur
Désactivez les différences colorées. C'est la même chose que --color=never.

--mot-diff[= ]
Afficher un mot diff, en utilisant le pour délimiter les mots modifiés. Par défaut, les mots sont
délimité par des espaces ; voir --word-diff-regex ci-dessous. Les par défaut à plaine,
et doit être l'un des :

Couleur
Mettez en surbrillance les mots modifiés en utilisant uniquement des couleurs. Implique --color.

plaine
Afficher les mots sous la forme [-removed-] et {+added+}. Ne fait aucune tentative pour échapper au
délimiteurs s'ils apparaissent dans l'entrée, la sortie peut donc être ambiguë.

porcelaine
Utilisez un format de ligne spécial destiné à la consommation de scripts.
Les séries ajoutées/supprimées/inchangées sont imprimées au format diff unifié habituel,
commençant par un caractère +/-/` ` au début de la ligne et s'étendant jusqu'à
La fin de la ligne. Les nouvelles lignes dans l'entrée sont représentées par un tilde ~ sur une ligne
de son propre.

aucun
Désactivez à nouveau la différence de mots.

Notez que malgré le nom du premier mode, la couleur est utilisée pour mettre en évidence le changement
pièces dans tous les modes si activé.

--word-diff-regex=
Utilisation pour décider ce qu'est un mot, au lieu de considérer des séries de non-espaces pour
être un mot. Implique également --word-diff à moins qu'il n'ait déjà été activé.

Chaque match sans chevauchement du est considéré comme un mot. N'importe quoi entre
ces correspondances sont considérées comme des espaces et ignorées (!) dans le but de trouver
différences. Vous pouvez ajouter |[^[:space:]] à votre expression régulière pour faire
assurez-vous qu'il correspond à tous les caractères non blancs. Une correspondance qui contient une nouvelle ligne est
silencieusement tronqué (!) à la nouvelle ligne.

Par exemple, --word-diff-regex=. traitera chaque caractère comme un mot et,
en conséquence, montrez les différences caractère par caractère.

L'expression régulière peut également être définie via un pilote diff ou une option de configuration, voir
attributs git(1) ou git-config(1). Le donner remplace explicitement tout pilote diff ou
paramètre de configuration. Les pilotes Diff remplacent les paramètres de configuration.

--color-mots[= ]
Équivalent à --word-diff=color plus (si une expression régulière a été spécifiée)
--word-diff-regex= .

--pas de renommage
Désactiver la détection de renommage, même lorsque le fichier de configuration donne la valeur par défaut à faire
de sorte.

--Chèque
Avertir si des modifications introduisent des erreurs d'espacement. Ce qui est considéré comme des erreurs d'espace est
contrôlé par la configuration core.whitespace. Par défaut, les espaces de fin
(y compris les lignes qui se composent uniquement d'espaces) et un caractère d'espace qui est
immédiatement suivi d'un caractère de tabulation à l'intérieur du retrait initial de la ligne sont
considéré comme des erreurs d'espaces. Sort avec un statut différent de zéro si des problèmes sont détectés. Pas
compatible avec --exit-code.

--ws-error-highlight=
Mettez en surbrillance les erreurs d'espacement sur les lignes spécifiées par dans la couleur spécifiée par
color.diff.whitespace. est une liste séparée par des virgules de l'ancien, du nouveau contexte. Lorsque
cette option n'est pas donnée, seules les erreurs d'espacement dans les nouvelles lignes sont mises en évidence. Par exemple
--ws-error-highlight=new,old met en évidence les erreurs d'espace blanc à la fois supprimées et ajoutées
lignes. tout peut être utilisé comme un raccourci pour l'ancien, le nouveau, le contexte.

--index-complet
Au lieu de la première poignée de caractères, affichez le blob complet avant et après l'image
les noms d'objet sur la ligne "index" lors de la génération d'une sortie au format patch.

--binaire
En plus de --full-index, génère un diff binaire qui peut être appliqué avec git-apply.

--abbrev[= ]
Au lieu d'afficher le nom complet de l'objet hexadécimal de 40 octets dans la sortie au format diff-raw
et les lignes d'en-tête diff-tree, n'affichent qu'un préfixe partiel. Ceci est indépendant de la
--full-index option ci-dessus, qui contrôle le format de sortie diff-patch. Non par défaut
le nombre de chiffres peut être spécifié avec --abbrev= .

-B[ ][/ ], --break-rewrites[=[ ][/ ]]
Divisez les modifications de réécriture complètes en paires de suppression et de création. Cela sert deux
fins:

Cela affecte la façon dont un changement qui équivaut à une réécriture totale d'un fichier non comme une série
de suppression et d'insertion mélangées avec très peu de lignes qui correspondent
textuellement comme contexte, mais comme une seule suppression de tout l'ancien suivi d'un
insertion unique de tout ce qui est nouveau, et le nombre m contrôle cet aspect du -B
option (par défaut à 60%). -B/70% spécifie que moins de 30% de l'original doit
restent dans le résultat pour que Git le considère comme une réécriture totale (c'est-à-dire sinon le
le correctif résultant sera une série de suppressions et d'insertions mélangées avec le contexte
lignes).

Lorsqu'il est utilisé avec -M, un fichier totalement réécrit est également considéré comme la source d'un
renommer (généralement -M ne considère qu'un fichier qui a disparu comme source d'un renommage),
et le nombre n contrôle cet aspect de l'option -B (par défaut à 50 %). -B20%
précise qu'un changement avec ajout et suppression par rapport à 20 % ou plus de la
la taille du fichier sont éligibles pour être récupérées comme source possible de renommage en
un autre fichier.

-M[ ], --find-renames[= ]
Détecter les renommages. Si n est spécifié, il s'agit d'un seuil sur l'indice de similarité (c'est-à-dire
nombre d'ajouts/suppressions par rapport à la taille du fichier). Par exemple, -M90% signifie
Git devrait considérer une paire suppression/ajout comme un renommage si plus de 90 % du fichier
n'a pas changé. Sans signe %, le nombre se lit comme une fraction, avec un
point décimal avant. C'est-à-dire que -M5 devient 0.5, et est donc identique à -M50%.
De même, -M05 est identique à -M5%. Pour limiter la détection aux renommages exacts, utilisez -M100 %.
L'indice de similarité par défaut est de 50 %.

-C[ ], --find-copies[= ]
Détecter les copies ainsi que les renommages. Voir aussi --find-copies-harder. Si n est spécifié, il
a la même signification que pour -M .

--trouver-des copies-plus difficiles
Pour des raisons de performances, par défaut, l'option -C ne trouve des copies que si le fichier d'origine
de la copie a été modifié dans le même ensemble de modifications. Ce drapeau fait inspecter la commande
fichiers non modifiés comme candidats pour la source de la copie. C'est un très cher
opération pour les grands projets, alors utilisez-le avec prudence. Donner plus d'une option -C
a le même effet.

-D, --irréversible-delete
Omettez la préimage pour les suppressions, c'est-à-dire n'imprimez que l'en-tête mais pas la différence entre les
preimage et /dev/null. Le patch résultant n'est pas destiné à être appliqué avec patch ou
git appliquer ; c'est uniquement pour les personnes qui veulent juste se concentrer sur l'examen de la
texte après le changement. De plus, la sortie manque manifestement d'assez d'informations pour
appliquer un tel patch à l'envers, même manuellement, d'où le nom de l'option.

Lorsqu'il est utilisé avec -B, omettez également la pré-image dans la partie de suppression d'un
supprimer/créer une paire.

-l
Les options -M et -C nécessitent un temps de traitement O(n^2) où n est le nombre de
cibles potentielles de renommage/copie. Cette option empêche l'exécution de la détection de renommage/copie
si le nombre de cibles de renommage/copie dépasse le nombre spécifié.

--diff-filter=[(A|C|D|M|R|T|U|X|B)...[*]]
Sélectionnez uniquement les fichiers ajoutés (A), copiés (C), supprimés (D), modifiés (M), renommés
(R), ont leur type (c'est-à-dire fichier régulier, lien symbolique, sous-module, ...) modifié (T), sont
Non fusionnés (U), sont inconnus (X) ou ont eu leur appariement brisé (B). Toute combinaison
des caractères de filtre (y compris aucun) peuvent être utilisés. Quand * (Tout ou rien) est ajouté
à la combinaison, tous les chemins sont sélectionnés s'il existe un fichier qui correspond à d'autres
critères dans la comparaison; s'il n'y a pas de fichier qui correspond à d'autres critères, rien
est sélectionné.

-S
Recherchez les différences qui modifient le nombre d'occurrences de la chaîne spécifiée
(c'est-à-dire ajout/suppression) dans un fichier. Destiné à l'usage du scripteur.

C'est utile lorsque vous recherchez un bloc de code exact (comme une structure) et que vous voulez
pour connaître l'historique de ce bloc depuis sa création : utilisez la fonction
itérativement pour réintroduire le bloc intéressant dans la pré-image dans -S, et continuer
jusqu'à ce que vous obteniez la toute première version du bloc.

-G
Recherchez les différences dont le texte du correctif contient des lignes ajoutées/supprimées qui correspondent .

Pour illustrer la différence entre -S --pickaxe-regex et -G , envisager
un commit avec le diff suivant dans le même fichier :

+ return !regexec(regexp, two->ptr, 1, ®match, 0);

- hit = !regexec(regexp, mf2.ptr, 1, ®match, 0);

Alors que git log -G"regexec\(regexp" affichera ce commit, git log -S"regexec\(regexp"
--pickaxe-regex ne le fera pas (car le nombre d'occurrences de cette chaîne n'a pas
monnaie).

Voir le pioche entrée dans gitdiffcore(7) pour plus d'informations.

--pioche-tout
Lorsque -S ou -G trouve un changement, affichez tous les changements dans cet ensemble de modifications, pas seulement le
fichiers qui contiennent le changement de .

--pioche-regex
Traiter le donné à -S en tant qu'expression régulière POSIX étendue pour correspondre.

-O
Sortez le patch dans l'ordre spécifié dans le , qui a un shell glob
motif par ligne. Cela remplace la variable de configuration diff.orderFile (voir git-
config(1)). Pour annuler diff.orderFile, utilisez -O/dev/null.

-R
Échangez deux entrées ; c'est-à-dire afficher les différences entre le fichier d'index ou le fichier sur disque et l'arborescence
Contenu.

--relative[= ]
Lorsqu'il est exécuté à partir d'un sous-répertoire du projet, il peut être dit d'exclure les modifications en dehors
le répertoire et afficher les chemins d'accès relatifs avec cette option. Quand tu n'es pas dans
un sous-répertoire (par exemple dans un référentiel nu), vous pouvez nommer le sous-répertoire à créer
la sortie par rapport à en donnant un comme argument.

-un texte
Traitez tous les fichiers comme du texte.

--ignorer-espace-at-eol
Ignorez les changements dans les espaces à EOL.

-b, --ignore-space-change
Ignorer les changements dans la quantité d'espaces. Cela ignore les espaces à la fin de la ligne et
considère que toutes les autres séquences d'un ou plusieurs caractères blancs sont équivalentes.

-w, --ignore-tout-espace
Ignorer les espaces lors de la comparaison de lignes. Cela ignore les différences même si une ligne a
espace où l'autre ligne n'en a pas.

--ignore-lignes-vides
Ignorez les modifications dont les lignes sont toutes vides.

--inter-hunk-context=
Afficher le contexte entre les différents morceaux, jusqu'au nombre de lignes spécifié, ainsi
fusionner des morceaux qui sont proches les uns des autres.

-W, --fonction-contexte
Montrez toutes les fonctions environnantes des changements.

--code de sortie
Faites sortir le programme avec des codes similaires à diff(1). C'est-à-dire qu'il sort avec 1 s'il y a
étaient des différences et 0 signifie aucune différence.

--silencieux
Désactivez toutes les sorties du programme. Implique --exit-code.

--ext-diff
Autorise l'exécution d'un assistant diff externe. Si vous définissez un pilote de diff externe avec
attributs git(5), vous devez utiliser cette option avec journal git(1) et amis.

--no-ext-diff
Interdire les pilotes de diff externes.

--textconv, --no-textconv
Autoriser (ou interdire) l'exécution de filtres de conversion de texte externes lors de la comparaison de fichiers binaires
des dossiers. Voir attributs git(5) pour plus de détails. Parce que les filtres textconv sont généralement un
conversion à sens unique, le diff résultant est adapté à la consommation humaine, mais ne peut pas
sois appliqué. Pour cette raison, les filtres textconv sont activés par défaut uniquement pour git-
diffde Géographie (1) et avec la journal git(1), mais pas pour git-format-correctif(1) ou commandes de plomberie diff.

--ignore-submodules[= ]
Ignorer les modifications apportées aux sous-modules dans la génération diff. peut être soit "aucun",
"untracked", "dirty" ou "all", qui est la valeur par défaut. L'utilisation de « aucun » prendra en compte le
sous-module modifié lorsqu'il contient soit des fichiers non suivis ou modifiés, soit son HEAD
diffère du commit enregistré dans le superprojet et peut être utilisé pour remplacer n'importe quel
paramètres de la ignorer option git-config(1) ou gitmodules(5). Lorsque "non suivi" est
les sous-modules utilisés ne sont pas considérés comme sales lorsqu'ils ne contiennent que du contenu non suivi (mais
ils sont toujours analysés pour le contenu modifié). L'utilisation de "dirty" ignore toutes les modifications apportées au
arbre de travail des sous-modules, seules les modifications apportées aux commits stockés dans le superprojet sont
montré (c'était le comportement jusqu'à la 1.7.0). L'utilisation de « all » masque toutes les modifications apportées à
sous-modules.

--src-prefix=
Affiche le préfixe source donné au lieu de "a/".

--dst-prefix=
Afficher le préfixe de destination donné au lieu de "b/".

--pas de préfixe
N'affiche aucun préfixe de source ou de destination.

Pour des explications plus détaillées sur ces options courantes, voir aussi gitdiffcore (7).


L'identifiant d'un objet arbre contre lequel effectuer la comparaison.

--caché
ne considérez pas du tout le fichier sur disque

-m
Par défaut, les fichiers enregistrés dans l'index mais non extraits sont signalés comme supprimés.
Ce drapeau fait jet indice de différence dire que tous les fichiers non extraits sont à jour.

RAW SORTIE Format

Le format de sortie brut 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é diffère :

git-diff-index
compare le et les fichiers sur le système de fichiers.

git-diff-index --cached
compare le et l'indice.

git-diff-tree [-r] [ ...]
compare les arbres nommés par les deux arguments.

git-diff-files [ ...]
compare l'index et les fichiers sur le système de fichiers.

La commande "git-diff-tree" commence sa sortie en imprimant le hachage de ce qui est en train d'être
par rapport. Après cela, toutes les commandes impriment une ligne de sortie par fichier modifié.

Une ligne de sortie est formatée de cette façon :

édition sur place : 100644 100644 bcd1234... 0123456... M fichier0
copie-édition : 100644 100644 abcd123... 1234567... C68 fichier1 fichier2
renommer-éditer : 100644 100644 abcd123... 1234567... R86 fichier1 fichier3
créer :000000 100644 0000000... 1234567... Un fichier4
supprimer :100644 000000 1234567... 0000000... D fichier5
non fusionné : 000000 000000 0000000... 0000000... Fichier U6

C'est-à-dire de gauche à droite :

1. un côlon.

2. mode pour "src" ; 000000 si création ou non fusionné.

3. un espace.

4. mode pour "dst" ; 000000 si suppression ou non fusionné.

5. un espace.

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

7. un espace.

8. sha1 pour "dst" ; 0{40} si création, non fusionné ou "regarder l'arbre de travail".

9. un espace.

10. statut, suivi du numéro de « score » facultatif.

11. une tabulation ou un NUL lorsque -z option est utilisée.

12. chemin pour "src"

13. une tabulation ou un NUL lorsque -z l'option est utilisée ; n'existe que pour C ou R.

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

15. un LF ou un NUL quand -z est utilisée pour terminer l'enregistrement.

Les lettres d'état possibles sont :

· A : ajout d'un fichier

· C : copie d'un fichier dans un nouveau

· D : suppression d'un fichier

· M : modification du contenu ou du mode d'un fichier

· R : renommer un fichier

· T : changement dans le type du fichier

· U : le fichier n'est pas fusionné (vous devez terminer la fusion avant de pouvoir le valider)

· X : type de changement « inconnu » (probablement un bug, veuillez le signaler)

Les lettres d'état C et R sont toujours suivies d'un score (indiquant le pourcentage de
similitude entre la source et la cible du déplacement ou de la copie). La lettre d'état M peut être
suivi d'un score (indiquant le pourcentage de dissemblance) pour les réécritures de fichiers.

s'affiche sous la forme de 1 si un fichier est nouveau sur le système de fichiers et qu'il n'est pas synchronisé avec
l'index.

Mise en situation :

:100644 100644 5be4a4...... 000000...... M fichier.c

Lorsque l'option -z n'est pas utilisée, les caractères TAB, LF et backslash dans les chemins sont représentés
comme \t, \n et \\, respectivement.

DIFFÉRENT Format POUR FUSIONNE

"git-diff-tree", "git-diff-files" et "git-diff --raw" peuvent prendre -c or --cc Option de
générer une sortie diff également pour les commits de fusion. La sortie diffère du format décrit
ci-dessus de la manière suivante :

1. il y a deux points pour chaque parent

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

3. le statut est des caractères de statut concaténés pour chaque parent

4. pas de numéro de « score » facultatif

5. chemin unique, uniquement pour "dst"

Mise en situation :

:: 100644 100644 100644 fabadb8... cc95eb0... 4866510... MM décrire.c

Notez que combiné diff répertorie uniquement les fichiers qui ont été modifiés à partir de tous les parents.

GÉNÉRATEUR PATCHS WITH -P

Lorsque "git-diff-index", "git-diff-tree" ou "git-diff-files" sont exécutés avec un -p option, "git
diff" sans le --cru option, ou "git log" avec l'option "-p", ils ne produisent pas le
sortie décrite ci-dessus ; à la place, ils produisent un fichier de correctif. Vous pouvez personnaliser la création
de ces correctifs via les variables d'environnement GIT_EXTERNAL_DIFF et GIT_DIFF_OPTS.

Ce que l'option -p produit est légèrement différent du format diff traditionnel :

1. Il est précédé d'un en-tête "git diff" qui ressemble à ceci :

diff --git a/fichier1 b/fichier2

Les noms de fichiers a/ et b/ sont les mêmes à moins qu'il ne s'agisse de renommer/copier. Surtout, même
pour une création ou une suppression, /dev/null est ne sauraient utilisé à la place de a/ ou b/
noms de fichiers.

Lorsque renommer/copier est impliqué, file1 et file2 affichent le nom du fichier source du
rename/copy et le nom du fichier que rename/copy produit, respectivement.

2. Il est suivi d'une ou plusieurs lignes d'en-tête étendues :

ancien mode
nouveau mode
mode fichier supprimé
nouveau mode de fichier
copier de
copier
renommer de
renommer en
indice de similitude
indice de dissemblance
indice ..

Les modes de fichier sont imprimés sous forme de nombres octaux à 6 chiffres, y compris le type de fichier et le fichier
bits d'autorisation.

Les noms de chemin dans les en-têtes étendus n'incluent pas les préfixes a/ et b/.

L'indice de similarité est le pourcentage de lignes inchangées, et l'indice de dissemblance
est le pourcentage de lignes modifiées. Il s'agit d'un nombre entier arrondi, suivi d'un
signe de pourcentage. La valeur de l'indice de similarité de 100 % est donc réservée à deux fichiers égaux,
alors que 100% de dissemblance signifie qu'aucune ligne de l'ancien fichier n'a été intégrée au nouveau
une.

La ligne d'index inclut la somme de contrôle SHA-1 avant et après le changement. Les est
inclus si le mode de fichier ne change pas ; sinon, des lignes séparées indiquent l'ancien
et le nouveau mode.

3. Les caractères TAB, LF, guillemets doubles et barre oblique inverse dans les chemins sont représentés par \t, \n,
\" et \\, respectivement. Si une telle substitution est nécessaire, l'ensemble
pathname est mis entre guillemets doubles.

4. Tous les fichiers file1 dans la sortie font référence à des fichiers avant la validation, et tous les fichiers file2
les fichiers font référence aux fichiers après la validation. Il est incorrect d'appliquer chaque changement à chaque
fichier séquentiellement. Par exemple, ce patch permutera a et b :

diff --git a/ab/b
renommer à partir d'un
renommer en b
diff --git a/bb/a
renommer de b
renommer en un

COMBINÉ DIFFÉRENT Format

Toute commande générant un diff peut prendre l'option -c ou --cc pour produire un combiné diff quand
montrant une fusion. Il s'agit du format par défaut lors de l'affichage des fusions avec git-diff(1) ou git-
montrer(1). Notez également que vous pouvez donner l'option -m à n'importe laquelle de ces commandes pour forcer
génération de différences avec les parents individuels d'une fusion.

A combiné diff le format ressemble à ceci :

diff --combiné décrit.c
index fabadb8,cc95eb0..4866510
--- a/décrire.c
+++ b/décrire.c
@@@ -98,20 -98,12 +98,20 @@@
retourner (a_date > b_date) ? -1 : (a_date == b_date) ? 0 : 1 ;
}

- description vide statique (car * arg)
-static void décrire (struct commit *cmit, int last_one)
++ static void describe(char *arg, int last_one)
{
+ caractère non signé sha1[20] ;
+ struct commit *cmit;
structure commit_list *liste;
int statique initialisé = 0 ;
struct commit_name *n;

+ si (get_sha1(arg, sha1) < 0)
+ utilisation(describe_usage);
+ cmit = lookup_commit_reference(sha1) ;
+ si (!cmit)
+ utilisation(describe_usage);
+
si (!initialisé) {
initialisé = 1 ;
for_each_ref(get_name);

1. Il est précédé d'un en-tête "git diff", qui ressemble à ceci (quand -c option est
utilisé):

diff --fichier combiné

ou comme ça (quand --cc option est utilisée):

diff --cc fichier

2. Il est suivi d'une ou plusieurs lignes d'en-tête étendues (cet exemple montre une fusion avec
deux parents) :

indice , ..
mode , ..
nouveau mode de fichier
mode fichier supprimé ,

La mode , .. n'apparaît que si au moins l'un des est
différent du reste. En-têtes étendus avec des informations sur les contenus détectés
mouvement (renommage et détection de copie) sont conçus pour fonctionner avec diff de deux
et ne sont pas utilisés par le format diff combiné.

3. Il est suivi d'un en-tête de deux lignes from-file/to-file

--- un fichier
+++ b/fichier

Similaire à l'en-tête à deux lignes pour le traditionnel unifiée diff, /dev/null est utilisé pour
signaler les fichiers créés ou supprimés.

4. Le format d'en-tête de morceau est modifié pour empêcher les gens de l'alimenter accidentellement à
patch -p1. Le format diff combiné a été créé pour l'examen des changements de validation de fusion, et
n'était pas destiné à s'appliquer. Le changement est similaire au changement de l'extension indice
en-tête:

@@@ @@@

Il y a (nombre de parents + 1) @ caractères dans l'en-tête de bloc pour les différences combinées
le format.

Contrairement au traditionnel unifiée format diff, qui montre deux fichiers A et B avec un seul
colonne qui a - (moins - apparaît dans A mais supprimé dans B), + (plus - manquant dans A mais
ajouté à B), ou le préfixe " " (espace — inchangé), ce format compare deux fichiers ou plus
fichier1, fichier2,... avec un fichier X, et montre en quoi X diffère de chacun des fichiersN. Une colonne
pour chacun des fichiers N est ajouté à la ligne de sortie pour noter en quoi la ligne de X est différente de
le

Un - caractère dans la colonne N signifie que la ligne apparaît dans le fichierN mais elle n'apparaît pas
dans le résultat. Un caractère + dans la colonne N signifie que la ligne apparaît dans le résultat,
et fileN n'a pas cette ligne (en d'autres termes, la ligne a été ajoutée, du point de
vue de ce parent).

Dans l'exemple de sortie ci-dessus, la signature de la fonction a été modifiée à partir des deux fichiers (d'où deux
- suppressions de file1 et file2, plus ++ pour signifier qu'une ligne qui a été ajoutée ne
apparaissent soit dans file1 soit dans file2). De plus, huit autres lignes sont identiques à partir de file1 mais ne
n'apparaît pas dans file2 (donc préfixé avec +).

Lorsqu'il est affiché par git diff-tree -c, il compare les parents d'un commit de fusion avec le merge
résultat (c'est-à-dire file1..fileN sont les parents). Lorsqu'il est affiché par git diff-files -c, il compare
les deux parents de fusion non résolus avec le fichier d'arbre de travail (c'est-à-dire que file1 est l'étape 2 aka
"notre version", file2 est l'étape 3 aka "leur version").

AUTRES DIFFÉRENT FORMATS

L'option --summary décrit les fichiers nouvellement ajoutés, supprimés, renommés et copiés. Le --stat
option ajoute diffstat(1) graphique à la sortie. Ces options peuvent être combinées avec d'autres
options, telles que -p, et sont destinés à la consommation humaine.

Lors de l'affichage d'un changement impliquant un changement de nom ou une copie, la sortie --stat formate le
chemins d'accès de manière compacte en combinant le préfixe et le suffixe communs des chemins d'accès. Par exemple, un
le changement qui déplace arch/i386/Makefile vers arch/x86/Makefile tout en modifiant 4 lignes sera
affiché comme ceci :

arch/{i386 => x86}/Makefile | 4 +--

L'option --numstat donne le diffstat(1) information mais est conçu pour une machine plus facile
consommation. Une entrée dans la sortie --numstat ressemble à ceci :

1 2 LISEZ-MOI
3 1 arch/{i386 => x86}/Makefile

C'est-à-dire de gauche à droite :

1. le nombre de lignes ajoutées ;

2. un onglet ;

3. le nombre de lignes supprimées ;

4. un onglet ;

5. chemin d'accès (éventuellement avec des informations de renommage/copie) ;

6. une nouvelle ligne.

Lorsque l'option de sortie -z est active, la sortie est formatée de cette façon :

1 2 LISEZ-MOI NUL
3 1 Arch NUL/i386/Makefile NUL arch/x86/Makefile NUL

C'est:

1. le nombre de lignes ajoutées ;

2. un onglet ;

3. le nombre de lignes supprimées ;

4. un onglet ;

5. un NUL (n'existe que s'il est renommé/copié) ;

6. chemin d'accès dans la préimage ;

7. un NUL (n'existe que s'il est renommé/copié) ;

8. chemin d'accès dans postimage (n'existe que s'il est renommé/copié) ;

9. un NUL.

Le NUL supplémentaire avant le chemin de la préimage dans le cas renommé est d'autoriser les scripts qui lisent le
sortie pour indiquer si l'enregistrement en cours de lecture est un enregistrement à chemin unique ou un renommer/copier
enregistrer sans lire à l'avance. Après lecture des lignes ajoutées et supprimées, lecture jusqu'à NUL
donnerait le nom de chemin, mais si c'est NUL, l'enregistrement affichera deux chemins.

EN FONCTIONNEMENT MODES

Vous pouvez choisir si vous voulez faire entièrement confiance au fichier d'index (à l'aide de la --caché drapeau)
ou demandez à la logique diff d'afficher tous les fichiers qui ne correspondent pas à l'état des statistiques comme étant
"provisoirement changé". Ces deux opérations sont en effet très utiles.

CACHÉ MODE

If --caché est spécifié, il permet de demander :

montre moi les différences entre HEAD et l'index actuel
contenu (ceux que j'écrirais en utilisant 'git write-tree')

Par exemple, disons que vous avez travaillé sur votre répertoire de travail, mis à jour certains fichiers
dans l'index et sont prêts à s'engager. Vous voulez voir exactement est ce que nous faisons vous allez
commit, sans avoir à écrire un nouvel objet arbre et à le comparer de cette façon, et pour ce faire,
tu fais juste

git diff-index --cached HEAD

Exemple : disons que j'avais renommé commit.c en git-commit.c, et que j'avais fait un update-index
pour que cela soit effectif dans le fichier d'index. git diff-files ne montrerait rien du tout,
puisque le fichier d'index correspond à mon répertoire de travail. Mais faire un jet indice de différence Est-ce que:

torvalds@ppc970 :~/git> git diff-index --cached HEAD
-100644 blob 4161aecc6700a2eb579e842af0b7f22b98443f74 commit.c
+100644 blob 4161aecc6700a2eb579e842af0b7f22b98443f74 git-commit.c

Vous pouvez voir facilement que ce qui précède est un changement de nom.

En fait, git diff-index --cached devrait toujours être tout à fait équivalent à réellement faire un
jet arbre-écriture et en comparant ça. Sauf que celui-ci est beaucoup plus agréable pour le cas où vous
Je veux juste vérifier où vous êtes.

Donc, faire un git diff-index --cached est fondamentalement très utile lorsque vous vous demandez
"qu'est-ce que j'ai déjà marqué pour être engagé, et quelle est la différence avec un précédent
arbre".

NON CACHÉ MODE

Le mode « non mis en cache » adopte une approche différente et est potentiellement le plus utile des
les deux en ce que ce qu'il fait ne peut pas être imité avec un jet arbre-écriture + jet arbre diff. Ainsi
c'est le mode par défaut. La version non mise en cache pose la question :

montrez-moi les différences entre HEAD et le actuellement vérifié
tree - indexe le contenu _et_ les fichiers qui ne sont pas à jour

ce qui est évidemment une question très utile aussi, car cela vous dit ce que vous pourriez s'engager.
Encore une fois, la sortie correspond à la jet arbre diff -r sortie à un tee, mais avec une torsion.

La torsion est que si un fichier ne correspond pas à l'index, nous n'avons pas de magasin de sauvegarde
chose pour cela, et nous utilisons la magie "tout zéro" sha1 pour le montrer. Alors disons que vous
ont édité kernel/sched.c, mais n'ont pas réellement fait de jet index-mise à jour dessus encore -
il n'y a pas d'"objet" associé au nouvel état, et vous obtenez :

torvalds@ppc970 :~/v2.6/linux> git diff-index --abbrev HEAD
:100644 100664 7476bb... 000000... noyau/sched.c

c'est-à-dire que cela montre que l'arborescence a changé et que kernel/sched.c n'est pas à jour
et peut contenir des nouveautés. Le sha1 tout à zéro signifie que pour obtenir le vrai diff, vous devez
regardez directement l'objet dans le répertoire de travail plutôt que de faire un objet à objet
diff.

Notes
Comme pour les autres commandes de ce type, jet indice de différence ne regarde pas réellement le
contenu du fichier du tout. Alors peut-être que kernel/sched.c n'a pas vraiment changé, et c'est
juste que tu l'as touché. Dans les deux cas, c'est une note que vous devez jet
index-mise à jour pour que l'index soit synchronisé.

Notes
Vous pouvez faire apparaître un mélange de fichiers comme « a été mis à jour » et « est toujours sale dans
le répertoire de travail" ensemble. Vous pouvez toujours savoir quel fichier est dans quel état,
puisque les "a été mis à jour" affichent un sha1 valide et les "non synchronisés avec le
index" auront toujours le sha1 spécial tout zéro.

GIT

Une partie de l' jet(1) Suite

Utilisez git-diff-index en ligne à l'aide des services onworks.net