Prendre le message de validation depuis le fichier indiqué. Utilisez - pour lire le message depuis l’entrée standard.

Au lieu d’appliquer la rustine, afficher le diffstat de l’entrée. Désactiver "appliquer".

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. Désactive "apply".

Au lieu d’appliquer la rustine, produire un résumé condensé des informations obtenues à partir des en-têtes étendus de git diff, tels que les créations, les renommages et les changements de mode. Désactive "apply".

Au lieu d’appliquer la rustine, voir si la rustine est applicable à l’arbre de travail actuel et/ou au fichier d’index et détecte les erreurs. Désactive "apply".

Appliquer la rustine à la fois à l’index et à l’arbre de travail (ou vérifier simplement qu’il s’appliquerait proprement aux deux si --check est en vigueur). Notez que --index s’attend à ce que les entrées de l’index et les copies de l’arbre de travail pour les chemins pertinents soient identiques (leur contenu et leurs métadonnées telles que le mode de fichier doivent correspondre), et qu’il générera une erreur si ce n’est pas le cas, même si la rustine s’applique proprement à l’index et à l’arbre de travail de manière isolée.

Appliquer la rustine uniquement sur l’index, sans toucher l’arbre de travail. Si la fonction --check est activée, vérifier simplement qu’elle s’applique correctement à l’entrée de l’index.

Lorsque de l’application de la rustine uniquement à l’arbre de travail, marquer les nouveaux fichiers à ajouter à l’index plus tard (voir l’option --intent-to-add dans git-add[1]). Cette option est ignorée sauf si elle est exécutée dans un dépôt Git et que --index n’est pas spécifié. Notez que --index peut être implicite par d’autres options telles que --cached ou --3way.

Tenter une fusion à 3 voies si la rustine enregistre l’identité des blobs auxquels elle est censée s’appliquer et que nous avons ces blobs disponibles localement, laissant éventuellement les marqueurs de conflit dans les fichiers de l’arbre de travail pour que l’utilisateur les résolve. Cette option implique l’option --index sauf si l’option --cached est utilisée, et est incompatible avec l’option --reject. Lorsqu’elle est utilisée avec l’option --cached, tous les conflits sont laissés à des étapes supérieures dans le cache.

La nouvelle sortie git diff contient des informations d’index pour chaque blob afin d’identifier la version originale à laquelle la rustine s’applique. Lorsque ce drapeau est donné, et si les versions originales des blobs sont disponibles localement, construire un index temporaire contenant ces blobs.

Appliquer la rustine à rebours.

Pour l’atomicité, git apply par défaut ne fonctionne pas sur l’ensemble de la rustine et ne touche pas l’arbre de travail lorsque certaines des sections ne s’appliquent pas. Cette option permet d’appliquer les parties de la rustine qui sont applicables et de laisser les sections rejetées dans les fichiers *.rej correspondants.

Lorsque le --numstat a été donné, ne pas changer les noms de chemin, mais utiliser un format lisible par machine et terminé par NUL.

Supprimer les composants <n> du chemin d’accès principal (séparés par des barres obliques) des chemins de diff traditionnels. Par exemple, avec -p2, une rustine contre a/dir/fichier sera appliquée directement à fichier. La valeur par défaut est 1.

S’assurer qu’au moins <n> lignes du contexte environnant correspondent avant et après chaque modification. Lorsqu’il y a moins de lignes de contexte environnant, elles doivent toutes correspondre. Par défaut, aucun contexte n’est jamais ignoré.

Par défaut, git apply s’attend à ce que la rustine appliquée soit un diff unifié avec au moins une ligne de contexte. Ceci fournit de bonnes mesures de sécurité, mais s’effondre lorsque l’on applique un diff généré avec --unified=0. Pour contourner ces vérifications, utilisez --unidiff-zero.

Si vous utilisez l’une des options marquées "Désactiver apply" ci-dessus, git apply lit et produit les informations demandées sans appliquer la rustine. Donnez ce drapeau après ces drapeaux pour appliquer également la rustine.

Lors de l’application d’une rustine, ignorer les ajouts faits par la rustine. Cette option peut être utilisée pour extraire la partie commune entre deux fichiers en exécutant d’abord diff sur ceux-ci et en appliquant le résultat avec cette option, ce qui appliquerait la partie de suppression mais pas la partie d’ajout.

Historiquement, nous n’autorisions pas l’application de rustines binaires sans une autorisation explicite de l’utilisateur, et ce drapeau était le moyen de le faire. Actuellement, nous autorisons toujours l’application de rustines binaires, donc c’est un non-op.

Ne pas appliquer les modifications aux fichiers correspondant au modèle de chemin donné. Cela peut être utile lors de l’importation d’ensembles de rustines, lorsque vous souhaitez exclure certains fichiers ou répertoires.

Appliquer les modifications aux fichiers correspondant au modèle de chemin donné. Cela peut être utile lors de l’importation d’ensembles de rustines, lorsque vous souhaitez inclure certains fichiers ou répertoires.

Lors de l’application d’une rustine, ignorer les modifications d’espaces blancs dans les lignes de contexte si nécessaire. Les lignes contextatives préserveront leurs espaces blancs, et elles ne subiront pas de correction d’espaces blancs quelle que soit la valeur de l’option --whitespace. Les nouvelles lignes seront toutefois encore corrigées.

Lors de l’application d’une rustine, détecter une ligne nouvelle ou modifiée qui comporte des erreurs d’espacement. Ce qui est considéré comme des erreurs d’espacement est contrôlé par la configuration core.whitespace. Par défaut, les espaces de fin de ligne (y compris les lignes qui ne sont composées que d’espaces) et un caractère espace qui est immédiatement suivi d’un caractère de tabulation à l’intérieur de l’indentation initiale de la ligne sont considérés comme des erreurs d’espacement.

Dans certaines circonstances, certaines versions de diff ne détectent pas correctement une nouvelle ligne manquante à la fin du fichier. Par conséquent, les rustines créées par ces programmes de diff n’enregistrent pas correctement les lignes incomplètes. Cette option permet d’appliquer ces rustines en contournant ce bogue.

Afficher l’état d’avancement sur stderr. Par défaut, seul un message concernant la rustine en cours d’application sera imprimé. Cette option entraînera l’affichage d’informations supplémentaires.

Ne pas se fier au nombre de lignes dans les en-têtes de sections, mais le déduire en inspectant la rustine (par exemple, après avoir modifié la rustine sans avoir ajusté les en-têtes de section de manière appropriée).

Préfixer <racine> à tous les noms de fichiers. Si un argument "-p" a également été passé, il est appliqué avant de préfixer la nouvelle racine.

Par défaut, une rustine qui affecte l’extérieur de la zone de travail (soit une arborescence de travail contrôlée par Git, soit le répertoire de travail actuel lorsque "git apply" est utilisé en remplacement de patch de GNU) est rejeté comme une erreur (ou un méfait).

Sélectionnez change si vous souhaitez que les modifications dans les espaces soient ignorées par défaut. Choisissez l’une des options suivantes : no, none, never, false si vous souhaitez que les modifications apportées aux espaces soient significatives.

Lorsqu’aucun drapeau --whitespace n’est donné en ligne de commande, cet élément de configuration est utilisé par défaut.