289

Ich habe einen bestimmten Patch namens my_pcc_branch.patch.

Wenn ich versuche, es anzuwenden, erhalte ich folgende Meldung:

$ 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

Was bedeutet das?

Wie kann ich dieses Problem beheben?

git msysgit

— Dmitrii Pisarenko
quelle

Liegen AbstractedPanel.java.rej-Dateien herum? Typisch bedeutet dies, dass sich ein Zeilenbot sowohl in der Quelle als auch im Patch geändert hat (hier scheint Zeile 13 betroffen zu sein).

— Rudi

Nein, ich habe keine * .rej-Dateien gefunden.

— Dmitrii Pisarenko

Sie sind sich nicht sicher, warum die akzeptierte Antwort das Problem beheben würde (ich bin also verdächtig, dass es sich um einen roten Hering handelt), aber bedeutet dies nicht has type 100644, expected 100755, dass irgendwo eine Nichtübereinstimmung der chmod-Berechtigungen vorliegt?

— Ruffin

325

git apply --reject --whitespace=fix mychanges.patch arbeitete für mich.

Erläuterung

Die --rejectOption weist git an, nicht fehlzuschlagen, wenn nicht festgelegt werden kann, wie ein Patch angewendet werden soll. Stattdessen können einzelne Hunks angewendet und Ablehnungsdateien ( .rej) für Hunks erstellt werden, die nicht angewendet werden können. Wiggle kann "[diese] abgelehnten Patches anwenden und wortweise Unterschiede ausführen".

Zusätzlich, --whitespace=fix vor Leerzeichenfehlern und versucht, diese zu beheben, anstatt sich zu weigern, einen ansonsten zutreffenden Teil anzuwenden.

Beide Optionen zusammen machen die Anwendung eines Patches robuster gegen Fehler, erfordern jedoch zusätzliche Aufmerksamkeit in Bezug auf das Ergebnis.

Die gesamte Dokumentation finden Sie unter https://git-scm.com/docs/git-apply .

— user1028904
quelle

8

Dies funktionierte tatsächlich besser für mich, weil es meine Datei nicht vollständig geändert hat

— Wayne Werner

10

Das ist toll. Lehnt einfach ab, was es nicht selbst lösen kann, und Sie können die abgelehnten Dateien einfach manuell ändern.

— Dennis

1

patch -p1 <mychanges.patch # wendet Änderungen Stück für Stück an. Wenn Änderungen fehlschlagen, werden ein Patch für <sourcefile> .orig und <sourcefile> .rej erstellt, und Sie können Änderungen manuell anwenden. Ich vermute, git apply --reject macht dasselbe und --whitespace = fix ist magisch besser.

— Gaoithe

7

Dieser Befehl erstellt .rejDateien, wenn nicht automatisch erkannt werden kann, wie ein Patch angewendet wird. Sie können Wackeln verwenden , um solche Probleme zu beheben.

— Goodniceweb

14

Diese Antwort erklärt nichts, insbesondere in welchen Fällen es funktionieren wird. Leute, man muss wirklich anspruchsvollere Antwortqualität haben, das ist SO kein Forum.

— Oliver

319

Johannes Sixt von der Mailingliste msysgit@googlegroups.com schlug vor, die folgenden Befehlszeilenargumente zu verwenden:

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

Dies löste mein Problem.

— Dmitrii Pisarenko
quelle

25

Kann mir jemand helfen und erklären, warum das funktioniert? Die andere Antwort funktionierte bei mir nicht und ich hatte genau das gleiche Problem wie das, was der Fragesteller beschreibt. Was haben Dateiattribute mit dem Ignorieren von Leerzeichen zu tun?

— Skrebbel

1

Verwenden von Windows Powershell Ein mit Git Diff erstellter Patch wurde wie folgt erfolgreich angewendet: Git Diff HEAD..613fee - myfile.xml | git apply --ignore-space-change --ignore-whitespace, während das erste Speichern der Diff-Ausgabe als Datei nicht funktionierte, falls jemand auf dasselbe Problem

— stößt

2

Versuchen Sie auch, auf "Anwenden" zu -C1wechseln. Dadurch wird der Kontext um Ergänzungen reduziert, die als wichtig angesehen werden.

— Amir Ali Akbari

2

@EricWalker, Git-Magie mit CR / LF ist nicht unbedingt eine schlechte Sache. Die Alternative kann sein, dass die Hälfte Ihrer Änderungssätze darin besteht, dass jede einzelne Zeile in jeder berührten Datei von einer Zeile zur anderen geändert wird, wobei die tatsächliche Änderung irgendwo in der Mitte vergraben ist.

— JWG

3

Das hilft manchmal. Aber manchmal bekomme ich immer noch den "Patch gilt nicht", obwohl der Patch ohne Probleme angewendet werden sollte.

— Thomas Levesque

118

Wenn alles andere fehlschlägt, versuchen Sie es mit git applyder --3wayOption .

git apply --3way patchFile.patch

--3way
Wenn der Patch nicht sauber angewendet wird , greifen Sie auf die 3-Wege-Zusammenführung zurück, wenn der Patch die Identität der Blobs aufzeichnet, auf die er angewendet werden soll, und wir diese Blobs lokal verfügbar haben und möglicherweise die Konfliktmarkierungen in den Dateien belassen Der Arbeitsbaum, den der Benutzer auflösen soll. Diese Option impliziert die Option --index und ist nicht mit den Optionen --reject und --cached kompatibel.

Ein typischer Fehlerfall wendet so viel Patch wie möglich an und führt zu Konflikten, die in git auftreten können, wie Sie es normalerweise tun. Wahrscheinlich ein Schritt einfacher als die rejectAlternative.

— Ruffin
quelle

2

Dies ist die Antwort, die für mich funktioniert hat. Die Datei, die ich gepatcht habe, spiegelte nicht die Änderungen wider, aus denen ich den Patch generiert habe (weil ich die Änderungen nach dem Erstellen des Patches gelöscht habe.)

— Christia

3

Schöne allgemeine Lösung. Das 3-Wege-Diff sah nicht so aus, als wäre es normalerweise etwas verwirrt, aber dennoch gab mir dies die Möglichkeit, den Konflikt zu lösen und den Patch zum Anwenden zu bringen.

— Steinybot

8

Ich denke, dies --3waysollte das Standardverhalten sein. Wenn das Patchen fehlschlägt, teilen Sie mir zumindest mit, was fehlgeschlagen ist, damit ich es manuell beheben kann. git applyscheitert einfach und meldet nicht, warum etwas fehlschlägt. Ich konnte nicht einmal *.rejDateien finden , wie sie hggeneriert wurden.

— Pavan Manjunath

4

Auf jeden Fall die beste Lösung. Lassen Sie den Benutzer seine eigenen Konflikte lösen!

— Mosh Feu

56

Dieser Befehl wendet den Patch an, ohne ihn zu beheben, und hinterlässt fehlerhafte Dateien wie folgt *.rej:

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

Sie müssen sie nur lösen. Einmal gelöst ausführen:

git -am resolved

— Ivan Voroshilin
quelle

7

Auflösen *.rej- Alles, was ich finden kann, ist, die Änderungen manuell in der Quelldatei vorzunehmen und diese .rejDateien zu löschen . Irgendein anderer Weg?

— Coding_idiot

1

@coding_idiot Wie üblich, überprüfen Sie einfach die .rej-Dateien, vergleichen Sie sie mit den widersprüchlichen Dateien und fügen Sie schließlich die festen Dateien zum Index hinzu (mit "git add FIXED_FILES")

— Ivan Voroshilin

2

@coding_idiot Sie konnten verwenden wackeln es zu lösen. Zum Beispiel : wiggle --replace path/to/file path/to/file.rej. Dieser Befehl übernimmt Änderungen von .rejDatei zu Originaldatei. Außerdem wird eine Kopie der Originaldatei erstellt, z path/to/file.porig. Bitte

— überprüfen

22

Versuchen Sie es mit der hier vorgeschlagenen Lösung: https://www.drupal.org/node/1129120

patch -p1 < example.patch

Das hat mir geholfen.

— Pini Cheyni
quelle

3

Ich weiß, dass du das nicht tun sollst, aber VIELEN DANK! Hat mir Stunden gespart. Ich bekam "Patch gilt nicht" und alle möglichen Fehler.

— Sudo RM-RF Slash

@ sudorm-rfslash, warum sollen wir das nicht machen und warum hast du es trotzdem gemacht?

— Schwarz

git: 'patch' is not a git command.amgit version 2.21.1 (Apple Git-122.3)

— Sridhar Sarnobat

16

Es passiert, wenn Sie UNIX- und Windows-Git-Clients mischen, weil Windows das Konzept des "x" rw-r--r---Bits nicht wirklich hat, sodass das Auschecken einer (0644) -Datei unter Windows von der msys-POSIX-Ebene als " rwx-r-xr-x(0755) " heraufgestuft "wird. . Git betrachtet diesen Modusunterschied im Grunde als einen Textunterschied in der Datei, sodass Ihr Patch nicht direkt angewendet wird. Ich denke, Ihre einzige gute Option ist es, core.filemodeauf false(using git-config) zu setzen.

Hier ist ein Problem mit msysgit mit verwandten Informationen: http://code.google.com/p/msysgit/issues/detail?id=164 (umgeleitet auf die Kopie von archive.org vom 3. Dezember 2013)

— Ben Jackson
quelle

2

Ich habe versucht, den Befehl "git config core.filemode false" auszuführen, aber es hat nicht geholfen - ich erhalte immer noch die gleiche Nachricht.

— Dmitrii Pisarenko

Angenommen, Sie haben keine nicht festgeschriebenen Änderungen in Ihrem Baum, versuchen Sie git reset --hard HEAD, git zu zwingen, Ihre Dateien mit der neuen Option erneut auszuchecken.

— Ben Jackson

Ich habe es gerade ausprobiert und "git reset --hard HEAD" ausgeführt. Es war erfolgreich (ich habe die Meldung "HEAD is now at ..." gesehen), aber das Problem mit "git apply" besteht weiterhin.

— Dmitrii Pisarenko

7

In meinem Fall war ich dumm genug, die Patch-Datei überhaupt falsch zu erstellen, und zwar auf die falsche Weise . Am Ende hatte ich genau die gleichen Fehlermeldungen.

Wenn Sie Master sind und dies tun git diff branch-name > branch-name.patch, wird versucht, alle gewünschten Ergänzungen zu entfernen und umgekehrt (was für Git unmöglich war, da natürlich nie vorgenommene Ergänzungen nicht entfernt werden können).

Stellen Sie also sicher, dass Sie zu Ihrer Filiale auschecken und ausführen git diff master > branch-name.patch

— Ophidian
quelle

3

WARNUNG: Mit diesem Befehl können alte verlorene Commits dauerhaft entfernt werden. Erstellen Sie eine Kopie Ihres gesamten Repositorys, bevor Sie dies versuchen.

Ich habe diesen Link gefunden

Ich habe keine Ahnung, warum dies funktioniert, aber ich habe viele Umgehungsmöglichkeiten ausprobiert und dies ist die einzige, die für mich funktioniert hat. Kurz gesagt, führen Sie die folgenden drei Befehle aus:

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

— Archmede
quelle

3

Dies ist ein sehr gefährlicher Befehl, mit dem alte verlorene Commits für immer aus dem Reflog entfernt werden können. Wenn Ihr Repo in einem wackeligen Zustand ist, wenden Sie dies nicht an.

— ET

0

Was ich gesucht habe, wird hier in SO nicht genau erwähnt. Ich schreibe zum Nutzen anderer, die nach ähnlichen suchen könnten. Ich hatte ein Problem mit einer Datei (im alten Repo vorhanden), die im Repo entfernt wurde. Und wenn ich den Patch anwende, schlägt er fehl, da die anzuwendende Datei nicht gefunden werden konnte. (Mein Fall ist also, dass der Git-Patch fehlschlägt, weil die Datei entfernt wurde.) '#git apply --reject' gab definitiv eine Ansicht, brachte mich aber nicht ganz zum Fix. Ich konnte wiggle nicht verwenden, da es für uns auf unseren Build-Servern nicht verfügbar ist. In meinem Fall habe ich dieses Problem gelöst, indem ich den Eintrag der 'Datei, die im Repo entfernt wurde' aus der Patch-Datei entfernt habe, die ich angewendet habe, sodass alle anderen Änderungen ohne Probleme angewendet wurden (3-Wege-Zusammenführung, Vermeidung Leerzeichenfehler) und dann das manuelle Zusammenführen des Inhalts der entfernten Datei an der Stelle, an der sie verschoben wurde.

— Bhanu
quelle

0

Mein Problem ist, dass ich ausgeführt habe git diff, dann ausgeführt habe git reset --hard HEADund dann realisiert habe, dass ich rückgängig machen wollte, also habe ich versucht, die Ausgabe von git diffin eine Datei zu kopieren und zu verwenden git apply, aber ich habe die Fehlermeldung erhalten, dass "Patch nicht angewendet wird". Nachdem ich zu ihm gewechseltpatch und versucht hatte, ihn zu verwenden, stellte ich fest, dass ein Teil des Diff aus irgendeinem Grund wiederholt wurde, und nachdem ich das Duplikat entfernt hatte patch(und vermutlich auch git apply), funktionierte es.

— Solomon Ucko
quelle

git: patch gilt nicht

Erläuterung

WARNUNG: Mit diesem Befehl können alte verlorene Commits dauerhaft entfernt werden. Erstellen Sie eine Kopie Ihres gesamten Repositorys, bevor Sie dies versuchen.