Як виправити повідомлення "Hunk # 1 FAILED at 1 (різних кінців рядка)"?

Я намагаюся створити патч із командою

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

коли я наношу пластир, він дає мені

$ 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

Я спробував застосувати dos2unix до src-файлу та патч-файлу, але повідомлення не пішло ...

UPD: - синьо-білі простори теж не допомагають

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: знайшов дуже гарну статтю: /programming//a/4425433/1709408

У мене була така ж проблема з використанням patchкоманди, яка поставляється з MSYS2 у Windows. У моєму випадку і вихідний файл, і патч мали закінчення CRLF, і перетворення обох у LF також не працювало. Працювало таке:

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

patch перетворить закінчення рядків у LF на всіх виправлених файлах, тому необхідно їх перетворити назад у CRLF.

Obs: patchверсія, яку я використовую, 2.7.5

Зазвичай ви можете обійти це за допомогою -lпараметра :

використовувати параметр -l або --ignore-whitespace, який змушує патч вільно порівнювати порожні символи (тобто пробіли та вкладки), щоб будь-яка непорожня послідовність заготовок у файлі патчу відповідала будь-якій непорожній послідовності пробілів у вхідних файлах

Це стандартна функція (див. Опис виправлення POSIX ).

Однак ОП внесла зміни до питання, щоб прокоментувати, як працюють конверсії рядків, що закінчуються з git core.autocrlf між різними операційними системами , і додала приклад, натякаючи на те, що проблема спостерігається з файлами в Windows (на відміну від прикладу в стилі Unix). Хоча patchнамагається вирішити невідповідність між закінченнями ліній CRLF та LF, у нього є ухил припускати, що останній використовується. Якщо файл патчу мав закінчення CRLF, а файли, які потрібно виправити, не відновився, він відновиться, як у цьому прикладі журналу:

(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

Перевіряючи вихідний код у своїй similarфункції, GNU patchрозглядає пробіл як spaceі Tab, з деяким спеціальним керуванням відповідно до того, чи мають рядки заднім LF. CR не згадується. Він звертає увагу check_line_endings, але використовує цю інформацію лише як частину повідомлення для діагностики відхилення. Він знімає кінцеві CR в pget_line, якщо не вказано --binaryпараметр.

Патч GNU не має можливості сказати йому перетворити патч із закінченнями LF у CRLF, щоб застосувати до файлів, рядкові закінчення яких є CRLF. Щоб надійно використовувати його в цьому випадку, вибір є

• конвертувати всі файли, щоб використовувати закінчення LF, або
• конвертувати всі файли для використання закінчень CRLF та додати --binaryопцію.

У Cygwin була аналогічна проблема. У моєму випадку виправленням було використання -iпрапора замість читання з stdin.

Не вдалося виконати помилку з різними закінченнями рядків :

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

Але вдалося наступне:

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

Я не впевнений у цій причині, але залишаю це тут, якщо хтось має те саме питання.