如何解决“ Hunk＃1 FAILED at 1（不同的行尾）”消息？

22

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

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

— 用户名
source

尝试sed -i.bak -e 's/\r$//g' something。我认为dos2unix不会像您想要的那样积极地处理混合行尾。

— Arthur2e5

彻头彻尾的邪恶；如果您的补丁带有与文件相同的CF-LF线尾，它将首先很高兴地从补丁中剥离CR，然后抛出一个适合的匹配，即线尾（刚断了）不匹配。

— SF。

5

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

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

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

Obs：patch我使用的版本是2.7.5

— 费尔南多·科斯塔·贝托迪
source

5

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

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

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

但是，OP修改了该问题，以注释行尾转换如何在不同的操作系统之间与git core.autocrlf一起使用，并添加了一个示例，暗示该问题在Windows上的文件中可见（与Unix风格的示例相反）。虽然patch尝试适应CRLF和LF线尾之间的不匹配，但有一个偏见，即假定使用后者。如果修补程序文件的结尾是CRLF，而要修补的文件没有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 根据行是否具有尾随LF进行一些特殊处理，patch将空格视为space和Tab。未提及CR。它确实注意了check_line_endings，但是仅将该信息用作消息的一部分，以帮助诊断拒绝。除非给出该选项，否则它将剥离pget_line中的尾随CR --binary。

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

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

— 托马斯·迪基
source

5

--ignore-whitespace（没有第二个破折号）也没有帮助，我更新了问题

— user1709408 2015年

0

我在Cygwin上遇到了类似的问题。就我而言，解决方法是使用-i标志而不是从标准输入中读取。

以下失败，出现不同的行尾错误：

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

但是以下成功：

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

我不确定原因，但是如果有人遇到同样的问题，就把它留在这里。

— 乔
source