Jak naprawić komunikat „Hunk # 1 FAILED at 1 (różne zakończenia linii)”?

Próbuję utworzyć łatkę za pomocą polecenia

git diff sourcefile >/var/lib/laymab/overlay/category/ebuild/files/thepatch.patch

kiedy nakładam łatkę, daje mi to

$ patch -v
GNU patch 2.7.5

$ /usr/bin/patch -p1 </var/lib/laymab/overlay/category/ebuild/files/thepatch.patch
patching file sourcefile
Hunk #1 FAILED at 1 (different line endings).
Hunk #2 FAILED at 23 (different line endings).
Hunk #3 FAILED at 47 (different line endings).
Hunk #4 FAILED at 65 (different line endings).
Hunk #5 FAILED at 361 (different line endings).
5 out of 5 hunks FAILED -- saving rejects to file sourcefile.rej

Próbowałem zastosować dos2unix zarówno do pliku src, jak i do pliku poprawki, ale komunikat nie zniknął ...

UPD: --ignore-whiteespace też nie pomaga

PATCH COMMAND:  patch -p1 -g0 -E --no-backup-if-mismatch --ignore-whitespace --dry-run -f < '/var/lib/layman/dotnet/dev-dotnet/slntools/files/remove-wix-project-from-sln-file-v2.patch'

=====================================================
checking file Main/SLNTools.sln
Hunk #1 FAILED at 14 (different line endings).
Hunk #2 FAILED at 49 (different line endings).
Hunk #3 FAILED at 69 (different line endings).
Hunk #4 FAILED at 102 (different line endings).
4 out of 4 hunks FAILED

UPD: znalazłem bardzo dobry artykuł: /programming//a/4425433/1709408

Miałem ten sam problem przy użyciu patchpolecenia dostarczanego z MSYS2 w systemie Windows. W moim przypadku zarówno plik źródłowy, jak i łatka miały koniec linii CRLF, a konwersja obu do LF również nie działała. To, co zadziałało, było następujące:

$ dos2unix patch-file.patch
$ patch -p1 < patch-file.patch
$ unix2dos modified-files...

patch przekonwertuje zakończenia linii na LF na wszystkich poprawionych plikach, więc konieczne jest przekonwertowanie ich z powrotem na CRLF.

Obs: patchużywam wersji 2.7.5

Zwykle można obejść ten problem, korzystając z -lopcji :

użyj opcji -l lub --ignore-whitespace, która powoduje, że łatka swobodnie porównuje puste znaki (tj. spacje i tabulatory), aby każda niepusta sekwencja pustych znaków w pliku łatek pasowała do dowolnej niepustej sekwencji pustych plików w plikach wejściowych

Jest to standardowa funkcja (patrz opis poprawki POSIX ).

Jednak OP zmieniło pytanie, aby skomentować, w jaki sposób konwersje kończące linię działają z git core.autocrlf między różnymi systemami operacyjnymi , i dodało przykład wskazujący, że problem występuje w przypadku plików w systemie Windows (w przeciwieństwie do przykładu w stylu uniksowym). Podczas gdy patchstara się dopasować niedopasowania między zakończeniami linii CRLF i LF, ma tendencję do zakładania, że ​​to drugie jest używane. Jeśli plik łatki miałby końce CRLF, a pliki do łatania nie, odzyskałby jak w tym dzienniku przykładowym:

(Stripping trailing CRs from patch.)
patching file xterm.log.html
(Stripping trailing CRs from patch.)
patching file xterm.man
(Stripping trailing CRs from patch.)
patching file xtermcfg.hin

Sprawdzając kod źródłowy, w similarfunkcji GNU patchtraktuje białe znaki jako spacei Tab, ze specjalną obsługą w zależności od tego, czy linie mają końcowy LF. CR nie jest wspomniany. Zwraca uwagę check_line_endings, ale wykorzystuje te informacje tylko jako część wiadomości, aby zdiagnozować odrzucenie. Usuwa końcowe CR w pget_line, chyba że --binarypodano opcję.

Łata GNU nie ma opcji, aby przekształcić łatkę z zakończeniami LF w CRLF w celu zastosowania do plików, których zakończeniami są CRLF. Aby użyć go niezawodnie w tym przypadku, dostępne są następujące opcje

• przekonwertować wszystkie pliki na końcówki LF, lub
• przekonwertuj wszystkie pliki, aby używały końcówek CRLF i dodaj --binaryopcję.

Miałem podobny problem na Cygwin. W moim przypadku poprawką było użycie -iflagi zamiast odczytu ze standardowego wejścia.

Następujące niepowodzenie z błędem różnych zakończeń linii :

patch -t -N -r - -p0 < patchfile

Ale udało się:

patch -t -N -r - -p0 -i patchfile

Nie jestem pewien przyczyny, ale zostawiam to tutaj na wypadek, gdyby ktoś miał ten sam problem.