Git
Français ▾ Topics ▾ Latest version ▾ git-apply last updated in 2.34.1

NOM

git-apply - Applique une rustine à des fichiers et/ou à l’index

SYNOPSIS

git apply [--stat] [--numstat] [--summary] [--check] [--index | --intent-to-add] [--3way]
	  [--apply] [--no-add] [--build-fake-ancestor=<fichier>] [-R | --reverse]
	  [--allow-binary-replacement | --binary] [--reject] [-z]
	  [-p<n>] [-C<n>] [--inaccurate-eof] [--recount] [--cached]
	  [--ignore-space-change | --ignore-whitespace]
	  [--whitespace=(nowarn|warn|fix|error|error-all)]
	  [--exclude=<chemin>] [--include=<chemin>] [--directory=<racine>]
	  [--verbose | --quiet] [--unsafe-paths] [--allow-empty] [<rustine>…​]

DESCRIPTION

Lit la sortie diff fournie (c’est-à-dire "une rustine") et l’applique aux fichiers. Lors de l’exécution à partir d’un sous-répertoire dans un dépôt, les chemins patchés en dehors du répertoire sont ignorés. Avec l’option --index, la rustine est également appliquée à l’index, et avec l’option --cached, la rustine est seulement appliquée à l’index. Sans ces options, la commande applique la rustine uniquement aux fichiers, et n’exige pas qu’ils soient dans un dépôt Git.

Cette commande applique la rustine mais ne crée pas de commit. Utilisez git-am[1] pour créer des commits à partir des rustines générées par git-format-patch[1] et/ou reçus par courrier électronique.

OPTIONS

<rustine>…​

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

--stat

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

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

--summary

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

--check

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

--index

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.

--cached

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.

--intent-to-add

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.

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

--build-fake-ancestor=<fichier>

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.

Lorsqu’un changement de mode pur est rencontré (qui n’a pas d’information d’index), l’information est lue à partir de l’index actuel à la place.

-R
--reverse

Appliquer la rustine à rebours.

--reject

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.

-z

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

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

-p<n>

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.

-C<n>

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

--unidiff-zero

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.

Notez que, pour les raisons mentionnées ci-dessus, l’utilisation de rustines sans contexte est découragée.

--apply

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.

--no-add

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.

--allow-binary-replacement
--binary

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.

--exclude=<motif-de-chemin>

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.

--include = <modèle-de-chemin>

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.

Lorsque des motifs --exclude et --include sont utilisés, ils sont examinés dans l’ordre où ils apparaissent sur la ligne de commande, et la première correspondance détermine si une rustine est utilisée pour chaque chemin. Une rustine pour un chemin qui ne correspond à aucun motif d’inclusion/exclusion est utilisée par défaut s’il n’y a pas de motif d’inclusion sur la ligne de commande, et ignorée s’il y a un motif d’inclusion.

--ignore-space-change
--ignore-whitespace

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.

--whitespace=<action>

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.

Par défaut, la commande émet des messages d’avertissement mais applique la rustine. Lorsque git-apply est utilisé pour des statistiques et non pour appliquer une rustine, la valeur par défaut est nowarn.

Vous pouvez utiliser différentes valeurs de <action> pour contrôler ce comportement :

  • nowarn désactive l’alerte d’espace blanc.

  • warn émet des avertissements pour quelques erreurs de ce type, mais applique la rustine tel quel (par défaut).

  • fix émet des avertissements pour quelques erreurs de ce type, et applique la rustine après les avoir corrigées (strip est un synonyme --- l’outil utilisé pour ne considérer que les caractères d’espacement de fin de ligne comme des erreurs, et le correctif impliquait de les "dépouiller" (stripping), mais les Gits modernes font plus).

  • error génère des avertissements pour quelques-unes de ces erreurs et refuse d’appliquer la rustine.

  • Le terme error-all est similaire à error mais montre toutes les erreurs.

--inaccurate-eof

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.

-v
--verbose

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.

-q
--quiet

Supprimer la sortie stderr. Les messages concernant l’état et la progression du rustinage ne seront pas imprimés.

--recount

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

--directory=<racine>

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 exemple, une rustine qui parle de mettre à jour a/git-gui.sh en b/git-gui.sh peut être appliquée au fichier dans l’arbre de travail modules/git-gui/git-gui.sh en lançant git apply --directory=modules/git-gui.

--unsafe-paths

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

Lorsque git apply est utilisé comme « meilleur patch GNU », l’utilisateur peut passer l’option --unsafe-paths pour passer outre cette vérification de sécurité. Cette option n’a aucun effet lorsque --index ou --cached est utilisé.

--allow-empty

Ne pas renvoyer d’erreur pour les rustines ne contenant pas de diff. Cela inclut les rustines vides et les rustines contenant uniquement du texte de validation.

CONFIGURATION

apply.ignoreWhitespace

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.

apply.whitespace

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

SOUS-MODULES

Si la rustine contient des modifications de sous-modules, alors git apply traite ces modifications comme suit.

Si --index est spécifié (explicitement ou implicitement), alors les commits du sous-module doivent correspondre exactement à l’index pour que la rustine s’applique. Si l’un des sous-modules est extrait, alors ces vérifications sont complètement ignorées, c’est-à-dire qu’il n’est pas nécessaire qu’il soit à jour ou propre et qu’il n’est pas mis à jour.

Si --index n’est pas spécifié, alors les commits de sous-module dans la rustine sont ignorées et seule l’absence ou la présence du sous-répertoire correspondant est vérifiée et (si possible) mise à jour.

VOIR AUSSI

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