J'ai un certain correctif appelé my_pcc_branch.patch.

Lorsque j'essaie de l'appliquer, je reçois le message suivant:

$ git apply --check my_pcc_branch.patch
warning: src/main/java/.../AbstractedPanel.java has type 100644, expected 100755
error: patch failed: src/main/java/.../AbstractedPanel.java:13
error: src/main/java/.../AbstractedPanel.java: patch does not apply

Qu'est-ce que ça veut dire?

Comment puis-je résoudre ce problème?

git apply --reject --whitespace=fix mychanges.patch travaillé pour moi.

Explication

L' --rejectoption demandera à git de ne pas échouer s'il ne peut pas déterminer comment appliquer un correctif, mais plutôt d'appliquer des morceaux individuels qu'il peut appliquer et de créer des fichiers de rejet ( .rej) pour les morceaux qu'il ne peut pas appliquer. Wiggle peut "appliquer [ces] correctifs rejetés et effectuer des différences au niveau des mots".

De plus, vous --whitespace=fixavertira des erreurs d'espace et essaiera de les corriger, plutôt que de refuser d'appliquer un morceau par ailleurs applicable.

Ensemble, les deux options rendent l'application d'un correctif plus robuste contre les pannes, mais elles nécessitent une attention supplémentaire en ce qui concerne le résultat.

Pour toute la documentation, voir https://git-scm.com/docs/git-apply .

Johannes Sixt de la liste de diffusion [email protected] a suggéré d'utiliser les arguments de ligne de commande suivants:

git apply --ignore-space-change --ignore-whitespace mychanges.patch

Cela a résolu mon problème.

Lorsque tout le reste échoue, essayez git applyl' --3wayoption .

git apply --3way patchFile.patch

--3way
Lorsque le patch ne s'applique pas correctement, retombez sur la fusion à 3 si le patch enregistre l'identité des blobs auxquels il est censé s'appliquer, et nous avons ces blobs disponibles localement, laissant éventuellement les marqueurs de conflit dans les fichiers dans l'arborescence de travail que l'utilisateur doit résoudre. Cette option implique l'option --index et est incompatible avec les options --reject et --cached.

Le cas d'échec typique applique autant de correctifs que possible et vous laisse avec des conflits à résoudre dans git comme vous le faites normalement. Probablement une étape plus facile que l' rejectalternative.

Cette commande appliquera le correctif sans le résoudre en laissant des fichiers incorrects comme *.rej:

git apply --reject --whitespace=fix mypath.patch

Il vous suffit de les résoudre. Une fois résolu, exécutez:

git -am resolved

Essayez d'utiliser la solution suggérée ici: https://www.drupal.org/node/1129120

patch -p1 < example.patch

Cela m'a aidé.

Cela se produit lorsque vous mélangez des clients git UNIX et Windows parce que Windows n'a pas vraiment le concept du bit "x", donc votre extraction d'un rw-r--r--fichier (0644) sous Windows est "promue" par la couche POSIX msys pour être rwx-r-xr-x(0755) . git considère que la différence de mode est fondamentalement la même qu'une différence textuelle dans le fichier, donc votre patch ne s'applique pas directement. Je pense que votre seule bonne option est de mettre ici core.filemodeà false( en utilisant git-config).

Voici un problème msysgit avec des informations connexes: http://code.google.com/p/msysgit/issues/detail?id=164 (redirigé vers la copie du 3 décembre 2013 d'Archive.org)

Dans mon cas, j'ai été assez stupide pour créer le fichier correctif de manière incorrecte en premier lieu, ce qui diffère en fait de la mauvaise façon . Je me suis retrouvé avec exactement les mêmes messages d'erreur.

Si vous êtes maître et que vous le faites git diff branch-name > branch-name.patch, cela essaie de supprimer tous les ajouts que vous souhaitez effectuer et vice versa (ce qui était impossible pour git car, évidemment, les ajouts jamais effectués ne peuvent pas être supprimés).

Assurez-vous donc de passer à la caisse de votre succursale et d'exécuter git diff master > branch-name.patch

AVERTISSEMENT: cette commande peut supprimer les anciennes validations perdues de façon PERMANENTE. Faites une copie de l'intégralité de votre référentiel avant d'essayer.

J'ai trouvé ce lien

Je ne sais pas pourquoi cela fonctionne mais j'ai essayé de nombreux contournements et c'est le seul qui a fonctionné pour moi. En bref, exécutez les trois commandes ci-dessous:

git fsck --full
git reflog expire --expire=now --all
git gc --prune=now

Ce que je cherchais n'est pas exactement indiqué ici dans SO, j'écris pour le bénéfice d'autres qui pourraient rechercher des similaires. J'ai rencontré un problème avec un fichier (présent dans l'ancien référentiel) supprimé dans le référentiel. Et lorsque j'applique le correctif, il échoue car il n'a pas pu trouver le fichier à appliquer. (donc mon cas est que le patch git échoue car le fichier a été supprimé) '#git apply --reject' a définitivement donné une vue mais ne m'a pas tout à fait apporté au correctif. Je ne pouvais pas utiliser wiggle car il n'est pas disponible pour nous dans nos serveurs de build. Dans mon cas, j'ai surmonté ce problème en supprimant l'entrée du `` fichier qui a été supprimé dans le référentiel '' du fichier de correctif que j'ai essayé d'appliquer, j'ai donc appliqué toutes les autres modifications sans problème (en utilisant la fusion à 3 voies, en évitant erreurs d'espace blanc), puis fusionner manuellement le contenu du fichier supprimé à l'endroit où il a été déplacé.

Mon problème est que j'ai couru git diff, puis couru git reset --hard HEAD, puis réalisé que je voulais annuler, j'ai donc essayé de copier la sortie de git diffdans un fichier et de l'utiliser git apply, mais j'ai eu une erreur que "le patch ne s'applique pas". Après le passage à patchet essayer de l' utiliser, je me suis aperçu qu'un morceau du différentiel a été répété pour une raison quelconque, et après avoir enlevé le double , patch(et sans doute aussi git apply) travaillé.