如何修复“Hunk #1 FAILED at 1(不同行结尾)”消息?

如何修复“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: --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

答案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

答案2

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

使用 -l 或 --ignore-whitespace 选项,这使得 patch 宽松地比较空白字符(即空格和制表符),以便补丁文件中的任何非空空白序列与输入文件中的任何非空空白序列相匹配

这是一个标准功能(参见POSIX 补丁描述)。

然而,OP修改了问题以发表评论行尾转换如何在不同操作系统之间使用 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将空格视为spaceTab,并根据行是否有尾随 LF 进行一些特殊处理。没有提到CR。它确实关注check_line_endings,但仅使用该信息作为消息的一部分来帮助诊断拒绝。它去掉了后面的 CRpget_line除非--binary给出了该选项。

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

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

答案3

我尝试了所有的解决方案,但由于某种原因它们失败了。相反,我通过更改我试图修补的文件上的行结尾来执行相反的操作,修补,然后将行结尾更改回我修补的文件中。

dos2unix <file I was trying to patch>
patch <any flags you need -- I was just using -p1> < patchfile
unix2dos <file I was trying to patch>

根据您的情况,您可能需要做相反的事情:

unix2dos <file I was trying to patch>
patch <any flags you need -- I was just using -p1> < patchfile
dos2unix <file I was trying to patch>

答案4

在我的例子中,结果是patch从这台机器上的 Strawberry Perl 安装调用的,它是第一个出现的%PATH%(并且 Cygwin 中根本没有安装补丁)。

总之,我尝试使用另一种补丁二进制文件来应用补丁,而不是创建补丁时使用的补丁二进制文件。

我安装patch在 Cygwin 中并明确调用/usr/bin/patch- 有效。

相关内容