Générer des correctifs normaux sans aucun diffstat.

Générer des diffs avec <n> lignes de contexte au lieu des trois habituelles.

Sortie vers un fichier spécifique au lieu de stdout.

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.

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.

Désactiver l’heuristique d’indentation.

Passer plus de temps pour s’assurer que le diff le plus petit possible est produit.

Générer un diff en utilisant l’algorithme « patience diff ».

Générer un diff en utilisant l’algorithme « diff histogramme ».

Générer un diff en utilisant l’algorithme « diff ancré ».

Choisir un algorithme de diff. Les variantes sont comme suit :

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> ou en réglant `diff.statGraphWidth=<largeur>. L’utilisation de --stat ou --stat-graph-width affecte toutes les commandes qui génèrent un graphique de stat, tandis que ré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.

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.

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.

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.

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 :

Synonyme de --dirstat=cumulative

Synonyme de --dirstat=files,param1,param2…​.

Afficher un résumé condensé d’information d’entête étendu tel que les créations, les renommages et les modifications de mode.

Désactiver la détection de renommage, même si le fichier de configuration indique de le faire par défaut.

S’il faut utiliser les blobs vides comme source de renommage.

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.

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

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

Casser les modifications de réécriture complète en paires de suppression et création. Cela sert deux objectifs :

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

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

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.

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.

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.

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.

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.

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.

Traiter tous les fichiers comme texte.

Ignorer les retours chariot en fin de ligne lors de la comparaison.

Ignorer les modifications d’espaces en fin de ligne.

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.

Ignorer les blancs lors de la comparaison de lignes. Ceci ignore les différences même si une ligne contient des espaces alors que l’autre n’en a pas.

Ignorer les modifications dont les lignes sont blanches.

Ignorer les modifications dont toutes les lignes correspondent à <regex>. Cette option peut être spécifiée plusieurs fois.

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.

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

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.

Désactiver les pilotes de diff externes.

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.

Ignorer les modifications à des sous-modules lors de la génération du diff. <quand> peut valoir "none" (aucun), "untracked" (non-suivi), "dirty" (sale) ou "all" (tout) qui est la valeur par défaut. L’utilisation de "none" va considérer comme modifiés les sous-modules quand ils contiennent soit des fichiers non-suivis ou modifiés, ou si sa HEAD diffère du commit enregistré dans le super-projet, et peut être utilisé pour passer outre tout réglage de l’option ignore dans git-config[1] ou gitmodules[5]. Quand "untracked" est utilisé, les sous-modules ne sont pas considérés sales quand ils ne contiennent que du contenu non suivi (mais ils sont quand même scannés pour trouver du contenu modifié). L’utilisation de "dirty" ignore toutes les modifications à l’arbre de travail des sous-modules ; seules les modifications aux commits stockés dans le super-projet sont affichées (c’était le comportement jusqu’à 1.7.0). La valeur "all" cache toutes les modifications des sous-modules.

Afficher le préfixe de source fourni au lieu de "a/".

Afficher le préfixe de destination fourni au lieu de "b/".

N’afficher aucun préfixe ni de source, ni de destination.

Utiliser les préfixes source et destination par défaut ("a/" et "b/"). C’est généralement déjà le cas par défaut, mais peut être utilisé pour surcharger une configuration telle que diff.noprefix.

Préfixer avec une chaîne additionnelle chaque ligne de la sortie.

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.

Préparer les rustines à partir des <n> commits les plus récents.

Utiliser <rép.> pour stocker les fichiers résultants, au lieu du répertoire de travail actuel.

Nommer la sortie au format [PATCH n/m], même avec une seule rustine.

Nommer la sortie au format [PATCH].

démarrer la numérotation des patchs à <n> au lieu de 1.

Les noms des fichiers de sortie seront une simple séquence de nombres sans la première ligne par défaut du commit ajouté.

Ne pas enlever/ajouter [PATCH] de la première ligne du message du journal de validation.

Ajouter une ligne terminale Signed-off-by au message de commit, en utilisant votre identité pour validateur. Référez-vous à l’option de contre-signature dans git-commit[1] pour plus d’information.

Afficher tous les commits sur la sortie standard au format mbox, au lieu de créer un fichier pour chacun d’entre eux.

Créer une pièce jointe multipart/mixte, dont la première partie est le message de validation et la deuxième partie la rustine elle-même, avec Content-Disposition : attachment.

Désactiver la création d’une pièce jointe, en remplaçant le paramètre de configuration.

Créer une pièce jointe multipart/mixte, dont la première partie est le message de validation et la deuxième partie la rustine elle-même, avec Content-Disposition : inline.

Contrôle l’ajout des en-têtes In-Reply-To et References pour que le deuxième courrier et les suivants apparaissent comme des réponses au premier. Contrôle également la génération de l’en-tête Message-ID à référencer.

Faire en sorte que le premier message (ou tous les messages si --no-thread est spécifié) apparaisse comme une réponse au <id message> donné, ce qui évite de casser les fils de discussion lors d’une nouvelle série de patchs.

Ne pas inclure une rustine qui correspond à un commit dans <jusque>..<depuis>. Ceci examinera tous les commits atteignables depuis <depuis> mais pas depuis <jusque> et les comparera avec les rustines en cours de génération, et toute rustine qui correspond sera ignorée.

Inclure les rustines pour les commits qui n’introduisent aucun changement, qui sont ignorés par défaut.

Contrôle les parties de la lettre d’introduction qui seront automatiquement remplies à l’aide de la description de la branche.

Utiliser le contenu de <fichier> au lieu de la description de la branche pour générer la lettre de d’introduction.

Au lieu du préfixe standard [PATCH] dans la ligne d’objet, utiliser plutôt '[<préfixe de l’objet>]. Cela peut être utilisé pour nommer une série de rustines, et peut être combiné avec l’option --numbered.

Au lieu de la longueur standard de 64 octets, les noms de fichiers de sortie générés sont réduits à environ <n> octets (une valeur trop courte sera augmentée silencieusement à une longueur raisonnable). La valeur par défaut est la valeur de la variable de configuration format.filenameMaxLength, ou 64 si non configuré.

Préfixe "RFC" au préfixe de sujet (créant "RFC PATCH" par défaut) . RFC signifie "Request For Comments" (demande de commentaires) ; utilisez ceci lorsque vous envoyez une rustine expérimentale pour une discussion plutôt que pour une application.

Marquer la série comme la <n>ième itération du sujet. Les noms des fichiers de sortie sont précédés de v<n>, et le préfixe du sujet ("PATCH" par défaut, mais configurable via l’option --subject-prefix) a ` v<n>` ajouté. Par exemple, --reroll-count=4 peut produire le fichier v4-0001-add-makefile.patch qui a "Subject : [PATCH v4 1/20] Add makefile". <n> n’a pas besoin d’être un nombre entier (par exemple, "--reroll-count=4.4", ou "--reroll-count=4rev2" sont autorisés), mais l’inconvénient d’utiliser un tel nombre de rerolls est que le range-diff/interdiff avec la version précédente n’indique pas exactement à quelle version la nouvelle iteration est comparée.

Ajoute un en-tête To: aux en-têtes du courriel. Ceci s’ajoute à tous les en-têtes configurés, et peut être utilisé plusieurs fois. La forme négative --no-to élimine tous les en-têtes To: ajoutés jusqu’à présent (depuis la configuration ou la ligne de commande).

Ajoute un en-tête Cc: aux en-têtes du courriel. Ceci s’ajoute à tous les en-têtes configurés, et peut être utilisé plusieurs fois. La forme négative --no-cc élimine tous les en-têtes Cc: ajoutés jusqu’à présent (depuis la configuration ou la ligne de commande).

Utiliser ident dans l’en-tête From: de chaque courriel de commit. Si l’identifiant de l’auteur du commit n’est pas textuellement identique au ident fourni, placer un en-tête From: dans le corps du message avec l’auteur original. Si aucun ident n’est fourni, utiliser l’identifiant du validateur.

Avec l’expéditeur du courriel spécifié par l’option --from, par défaut, un "From :" dans le corps du message pour identifier l’auteur réel du commit est ajouté en haut du message du journal des validations si l’expéditeur est différent de l’auteur. Avec cette option, le "From :" dans le corps du message est ajouté même si l’expéditeur et l’auteur ont le même nom et la même adresse, ce qui peut aider si le logiciel de liste de diffusion confond l’identité de l’expéditeur. La valeur par défaut est la valeur de la variable de configuration format.forceInBodyFrom.

Ajoute un entête arbitraire aux entêtes du courriel. Ceci s’ajoute à tous les entêtes configurés, et peut être utilisé plusieurs fois. Par exemple, --add-header="Organisation : git-foo". La forme négative --no-add-header élimine tous les entêtes (To:, Cc:, et personnalisés) ajoutés jusqu’ici depuis la configuration ou la ligne de commande.

En plus des rustine, générer un fichier de lettre d’introduction contenant la description de la branche, le shortlog et le diffstat global. Vous pouvez remplir une description dans le fichier avant de l’envoyer.

Encoder les entêtes de courriel qui contiennent des caractères non ASCII avec le "Q-encoding" (décrit dans la RFC 2047), au lieu d’afficher les entêtes textuellement. La valeur par défaut est la valeur de la variable de configuration format.encodeEmailHeaders.

Pour aider à la revue, insérer un interdiff dans la lettre d’introduction, ou comme commentaire de la rustine d’une série d’une seule rustine, montrant les différences entre la version précédente de la série de rustines et la série en cours de formatage. précédent est une révision unique nommant la pointe de la série précédente qui partage une base commune avec la série en cours de formatage (par exemple git format-patch --cover-letter --interdiff=feature/v1 -3 feature/v2).

Pour aider à la revue, insérer un range-diff (voir git-range-diff[1]) dans la lettre d’introduction, ou comme commentaire de la rustine d’une série d’une seule rustine, montrant les différences entre la version précédente de la série de rustines et la série en cours de formatage. précédent peut être une révision unique nommant la pointe de la série précédente si elle partage une base commune avec la série en cours de formatage (par exemple git format-patch --cover-letter --range-diff=feature/v1 -3 feature/v2), ou une plage de révisions si les deux versions de la série sont disjointes (par exemple git format-patch --cover-letter --range-diff=feature/v1~3..feature/v1 -3 feature/v2).

Utilisé avec --range-diff, modifie l’heuristique qui fait correspondre les commits entre la série précédente et la série actuelle de rustines en ajustant le facteur de correction du coût de création/suppression. Voir git-range-diff[1]) pour plus de détails.

Ajouter les notes (voir git-notes[1]) pour le commit après la ligne à trois tirets.

Ajouter une signature à chaque message produit. Selon la RFC 3676, la signature est séparée du corps du message par une ligne avec --. Si l’option signature est omise, la signature est par défaut le numéro de version de Git.

Fonctionne comme --signature, sauf que la signature est lue depuis un fichier.

Au lieu d’utiliser .patch comme suffixe pour les noms de fichiers générés, utiliser le suffixe spécifié. Une alternative courante est --suffix=.txt. Si cette option est laissée vide, le suffixe .patch sera supprimé.

Ne pas afficher les noms des fichiers générés sur la sortie standard.

Ne pas afficher le contenu des modifications dans les fichiers binaires, mais plutôt un avis que ces fichiers ont été modifiés. Les rustines générées à l’aide de cette option ne peuvent pas être appliquées correctement, mais elles sont toujours utiles pour une revue du code.

Affiche une empreinte entièrement nulle dans l’en-tête From de chaque rustine au lieu de l’empreinte du commit.

Enregistrer les informations sur l’arbre de base pour identifier l’état auquel la série de rustines s’applique. Voir la section INFORMATION SUR L’ARBRE DE BASE ci-dessous pour plus de détails. Si <commit> est "auto", un commit de base est automatiquement choisi. L’option --no-base remplace la valeur configurée dans format.useAutoBase.

Traiter l’argument révision comme une <plage de révisions>, même s’il ne s’agit que d’un seul commit (qui serait normalement traité comme un <depuis>). Notez que les commits racines inclus dans l’intervalle spécifié sont toujours formatés comme des rustines de création, indépendamment de ce drapeau.

Afficher des rapports de progression sur stderr au fur et à mesure que les rustines sont générées.