如何修复“Hunk #1 FAILED at 1（不同的行尾）”消息？

Question

我正在尝试使用命令创建补丁

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：--ignore-whitespace 也无济于事

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：发现一篇很好的文章：https : //stackoverflow.com/a/4425433/1709408

Answer 1

我patch在 Windows 上使用 MSYS2 附带的命令时遇到了同样的问题。在我的情况下，源文件和补丁都有 CRLF 行尾，并且将两者都转换为 LF 也不起作用。有效的是以下内容：

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

patch 会将所有修补文件的行尾转换为 LF，因此有必要将它们转换回 CRLF。

Obs：patch我使用的版本是 2.7.5

Answer 2

您通常可以使用以下-l选项解决此问题：

使用 -l 或 --ignore-whitespace 选项，这使补丁松散地比较空白字符（即空格和制表符），以便补丁文件中的任何非空空白序列匹配输入文件中的任何非空空白序列

这是标准功能（请参阅POSIX 补丁说明）。

但是，OP 修改了问题以评论How line end conversions work with 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函数中，GNUpatch将空格视为spaceand Tab，并根据行是否有尾随 LF 进行一些特殊处理。没有提到CR。它确实关注check_line_endings，但仅使用该信息作为消息的一部分来帮助诊断拒绝。除非给出选项，否则它会删除 pget_line 中的尾随 CR --binary。

GNU 补丁没有选项告诉它将带有 LF 结尾的补丁转换为 CRLF 以应用于行结尾为 CRLF 的文件。为了在这种情况下可靠地使用它，选择是

• 将所有文件转换为使用 LF 结尾，或
• 将所有文件转换为使用 CRLF 结尾并添加--binary选项。