git: łatka nie ma zastosowania

289

Mam pewną łatkę o nazwie my_pcc_branch.patch.

Kiedy próbuję go zastosować, pojawia się następujący komunikat:

$ 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

Co to znaczy?

Jak mogę rozwiązać ten problem?

Dmitrii Pisarenko
źródło
Czy leżą jakieś pliki AbstractedPanel.java.rej? Typowo oznacza to, że bot linii zmienił się zarówno w źródle, jak iw łatce (tutaj wydaje się, że dotyczy to linii 13).
Rudi
Nie, nie znalazłem żadnych plików * .rej.
Dmitrii Pisarenko
Nie jestem pewien, dlaczego zaakceptowana odpowiedź to naprawi (więc podejrzewam, że to czerwony śledź), ale nie has type 100644, expected 100755oznacza to, że gdzieś istnieje niedopasowanie uprawnień chmod?
ruffin

Odpowiedzi:

325

git apply --reject --whitespace=fix mychanges.patch pracował dla mnie.

Wyjaśnienie

Ta --rejectopcja sprawi, że git nie zawiedzie, jeśli nie będzie w stanie określić, jak zastosować łatkę, ale zamiast zastosować indywidualne porcje, może zastosować i utworzyć pliki odrzucania ( .rej) dla porcji, których nie może zastosować. Wiggle może „zastosować [te] odrzucone łatki i wykonać słowne różnice”.

Dodatkowo --whitespace=fixbędzie ostrzegał o błędach białych znaków i spróbuje je naprawić, zamiast odmawiać zastosowania skądinąd właściwego przystojniaka.

Obie opcje razem sprawiają, że aplikacja łatki jest bardziej odporna na awarie, ale wymagają dodatkowej uwagi w odniesieniu do wyniku.

Całą dokumentację można znaleźć na stronie https://git-scm.com/docs/git-apply .

użytkownik1028904
źródło
8
To faktycznie działało dla mnie lepiej, ponieważ nie całkowicie zmodyfikowało mój plik
Wayne Werner
10
To jest świetne. Po prostu odrzuca to, czego sam nie może rozwiązać, a następnie możesz po prostu ręcznie zmodyfikować odrzucone pliki.
Dennis
1
patch -p1 <mychanges.patch # stosuje zmiany fragment po kawałku. Jeśli zmiany się nie powiodą, tworzona jest łatka <sourcefile> .orig i <sourcefile> .rej, które można zastosować ręcznie. Domyślam się, że git stosuje - odrzuć robi to samo, a --whitespace = fix jest magicznie lepszy.
gaoithe
7
to polecenie tworzy .rejpliki, gdy nie można automatycznie wykryć sposobu zastosowania poprawki. Możesz użyć wiggle do rozwiązania takich problemów.
goodniceweb 30.04.16
14
Ta odpowiedź nic nie wyjaśnia, w szczególności w jakich przypadkach będzie działać. Ludzie, naprawdę trzeba być bardziej wymagającym od jakości odpowiedzi, to NIE jest forum.
Oliver
319

Johannes Sixt z listy mailingowej [email protected] zasugerował użycie następujących argumentów wiersza poleceń:

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

To rozwiązało mój problem.

Dmitrii Pisarenko
źródło
25
Czy ktoś może mi pomóc i wyjaśnić, dlaczego to działa? Inna odpowiedź nie działała dla mnie i miałem dokładnie ten sam problem, co opisujący pytający. Co mają wspólnego atrybuty pliku z ignorowaniem białych znaków?
skrebbel
1
Korzystanie z Windows PowerShell Łatka utworzona za pomocą git diff została pomyślnie zastosowana w następujący sposób: git diff HEAD..613fee - myfile.xml | git stosuje --ignore-space-change --ignore-whitespace, podczas gdy pierwsze zapisywanie wyjścia diff jako pliku nie działało, na wypadek, gdyby ktoś napotkał ten sam problem
tjb
2
także spróbuj -C1zmienić na zastosowanie, zmniejsza kontekst wokół dodatków, które są uważane za ważne.
Amir Ali Akbari,
2
@EricWalker, git magic z CR / LF niekoniecznie jest złą rzeczą. Alternatywą może być to, że połowa twoich zestawów zmian składa się z każdej linii w każdym dotkniętym pliku, zmienianej z jednej linii na drugą, z faktyczną zmianą ukrytą gdzieś pośrodku.
jwg
3
To czasem pomaga. Ale innym razem wciąż pojawia się komunikat „łatka nie ma zastosowania”, mimo że łatka powinna być stosowana bez problemów.
Thomas Levesque
118

Kiedy wszystko inne zawiedzie, spróbuj git apply„s --3wayopcję .

git apply --3way patchFile.patch

--3way
Gdy łatka nie stosuje się czysto, cofnij się na łączeniu 3-kierunkowym, jeśli łatka rejestruje tożsamość obiektów blob, do których ma się zastosować, a my mamy te obiekty BLOB dostępne lokalnie, prawdopodobnie pozostawiając znaczniki konfliktu w plikach w drzewo robocze do rozwiązania przez użytkownika. Ta opcja implikuje opcję --index i jest niezgodna z opcjami --reject i --cached.

Typowy przypadek awarii dotyczy jak największej liczby łatek i pozostawia cię z konfliktami do rozwiązania w git, jak zwykle to robisz. Prawdopodobnie o jeden krok łatwiej niż rejectalternatywa.

bułka z masłem
źródło
2
To była odpowiedź, która zadziałała dla mnie. Plik, który łatałem, nie odzwierciedlał zmian, z których wygenerowałem łatkę (ponieważ usunąłem zmiany po utworzeniu łatki.)
Christia
3
Ładne ogólne rozwiązanie. 3way diff nie wyglądał tak, jakby normalnie to robiło to trochę zdezorientowane, ale mimo to dało mi to możliwość rozwiązania konfliktu i uzyskania łatki do zastosowania.
steinybot
8
Myślę, że --3waypowinno to być zachowanie domyślne. Gdy łatanie się nie powiedzie, przynajmniej powiedz mi, co się nie udało, abym mógł to naprawić ręcznie. git applypo prostu zawodzi i nie informuje, dlaczego coś się nie udaje. Nie mogłem nawet znaleźć *.rejplików takich jak te hggenerowane.
Pavan Manjunath
4
Zdecydowanie najlepsze rozwiązanie. Pozwól użytkownikowi rozwiązać własne konflikty!
Mosh Feu,
56

To polecenie zastosuje łatkę nie rozwiązującą jej, pozostawiając złe pliki jako *.rej:

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

Musisz je tylko rozwiązać. Po rozwiązaniu uruchom:

git -am resolved
Ivan Voroshilin
źródło
7
jak rozwiązać *.rej- wszystko, co mogę znaleźć, to ręcznie wprowadzić zmiany w pliku źródłowym i usunąć te .rejpliki. W jakikolwiek inny sposób?
coding_idiot
1
@coding_idiot Jak zwykle, po prostu sprawdź pliki .rej, porównaj je z plikami powodującymi konflikty i na koniec dodaj poprawione pliki do indeksu (z „git add FIXED_FILES”)
Ivan Voroshilin
2
@coding_idiot możesz użyć wiggle, aby go rozwiązać. Na przykład: wiggle --replace path/to/file path/to/file.rej. To polecenie zastosuje zmiany z .rejpliku do oryginalnego pliku. Tworzy również kopię oryginalnego pliku, na przykład path/to/file.porig. Proszę
sprawdzić
22

Spróbuj użyć rozwiązania zaproponowanego tutaj: https://www.drupal.org/node/1129120

patch -p1 < example.patch

To mi pomogło.

Pini Cheyni
źródło
3
Wiem, że nie powinieneś tego robić, ale DZIĘKUJĘ TAK DUŻO! Oszczędził mi godziny. Otrzymywałem „łatkę nie dotyczy” i wszelkiego rodzaju błędy.
sudo rm -rf slash
@ sudorm-rfslash, dlaczego nie powinniśmy tego robić i dlaczego to robiliście?
Czarny
git: 'patch' is not a git command.ongit version 2.21.1 (Apple Git-122.3)
Sridhar Sarnobat
16

Zdarza się to, gdy miksujesz klientów git w systemie UNIX i Windows, ponieważ system Windows tak naprawdę nie ma pojęcia „x”, więc rw-r--r--pobranie pliku (0644) w systemie Windows jest „promowane” przez warstwę msys POSIX jako rwx-r-xr-x(0755) . git uważa, że ​​różnica trybów jest zasadniczo taka sama jak różnica tekstowa w pliku, więc łatka nie ma bezpośredniego zastosowania. Myślę, że jedynym dobrym rozwiązaniem jest, aby ustawić core.filemodesię false(za pomocą git-config).

Oto problem msysgit z niektórymi powiązanymi informacjami: http://code.google.com/p/msysgit/issues/detail?id=164 (przekierowany do kopii archive.org z 3 grudnia 2013 r.)

Ben Jackson
źródło
2
Próbowałem uruchomić polecenie „git config core.filemode false”, ale to nie pomogło - wciąż otrzymuję ten sam komunikat.
Dmitrii Pisarenko
Zakładając, że nie ma żadnych niezatwierdzonych zmian w drzewie, spróbuj git reset --hard HEADzmusić git do ponownego pobrania plików z nową opcją.
Ben Jackson
Właśnie wypróbowałem to wykonać polecenie „git reset --hard HEAD”. Udało się (zobaczyłem komunikat „HEAD jest teraz w ...”), ale problem z „git Apply” nadal występuje.
Dmitrii Pisarenko
7

W moim przypadku byłem na tyle głupi, że w pierwszej kolejności niepoprawnie utworzyłem plik łatki, właściwie źle robiąc . Skończyłem z tymi samymi komunikatami o błędach.

Jeśli jesteś mistrzem i zrób to git diff branch-name > branch-name.patch , to próbuje usunąć wszystkie dodatki, które chcesz się zdarzyć i na odwrót (co było niemożliwe do osiągnięcia przez git, ponieważ, oczywiście, nigdy nie zrobiono żadnych dodatków, których nie można usunąć).

Upewnij się więc, że zameldujesz się w swoim oddziale i wykonasz git diff master > branch-name.patch

Ophidian
źródło
3

OSTRZEŻENIE: To polecenie może trwale usunąć stare utracone zatwierdzenia. Zrób kopię całego repozytorium przed próbą wykonania tego.

Znalazłem ten link

Nie mam pojęcia, dlaczego to działa, ale próbowałem wielu obejść i to jest jedyna, która działała dla mnie. Krótko mówiąc, uruchom trzy poniższe polecenia:

git fsck --full
git reflog expire --expire=now --all
git gc --prune=now
Archmede
źródło
3
Jest to bardzo niebezpieczne polecenie, które może na zawsze usunąć stare utracone zatwierdzenia z rejestru. Jeśli Twoje repozytorium jest niepewne, NIE STOSUJ TEGO.
ET
0

To, czego szukałem, nie zostało dokładnie wskazane tutaj w SO, piszę z korzyścią dla innych, którzy mogą szukać podobnych. Wystąpił problem z usunięciem jednego pliku (obecnego w starym repozytorium). A kiedy zastosuję łatkę, nie powiedzie się, ponieważ nie można znaleźć pliku do zastosowania. (więc mój przypadek jest taki, że łatka git kończy się niepowodzeniem, ponieważ plik został usunięty) „#git Apply --reject” zdecydowanie dał widok, ale nie całkiem mnie naprawił. Nie mogłem użyć wiggle, ponieważ nie jest on dostępny na naszych serwerach kompilacji. W moim przypadku przeszedłem przez ten problem, usuwając wpis „pliku, który został usunięty z repozytorium” z pliku łatki, który próbowałem zastosować, więc wszystkie inne zmiany zostały zastosowane bez problemu (używając scalania 3-kierunkowego, unikając błędy białych znaków), a następnie ręcznie scalając zawartość pliku usuniętą do miejsca, w którym został przeniesiony.

Bhanu
źródło
0

Mój problem polega na tym, że uruchomiłem git diff, potem uruchomiłem git reset --hard HEAD, a potem zdałem sobie sprawę, że chcę cofnąć, więc próbowałem skopiować dane wyjściowe git diffdo pliku i używać git apply, ale dostałem błąd, że „łata nie ma zastosowania”. Po przełączeniu się patchi stara się go używać, zdałem sobie sprawę, że klocek diff powtórzono z jakiegoś powodu, a po usunięciu duplikatów , patch(i prawdopodobnie również git apply) pracował.

Solomon Ucko
źródło