Question

我尝试应用包含git apply二进制文件的修补程序，但只添加了文件。我尝试运行git apply failing.patch -v并打印出类似的内容：

跳过补丁＆＃39; file.txt＆＃39;。
  检查补丁文件.bin ...
  干净地应用补丁文件。

如何找出跳过原因的原因？由于目前的信息不是很有启发性。

Answer 1

我通过运行打印的patch -p1 < failing.patch找到了问题：

无法在输入第5行找到要修补的文件

并提醒我，我不在根目录中。

我无法理解为什么no one had asked this before以及为什么详细信息不详细。

此外，甚至official documentation都没有提及跳过和可能的原因。

Answer 2

如果使用--directory选项来“ git apply”：

  --directory=<root>

该路径与基本目录（包含“ .git”的目录）相关，而不是相对于当前工作目录。您也不能使用绝对路径。

这是完全没有记载的，花了我几个小时才发现。

Answer 3

尝试在项目之间移植更改时遇到此问题。 git apply似乎忽略了修补程序文件路径上的任何目录名称，如果索引行与目标存储库中的文件哈希不匹配，它也会拒绝应用。我使用这些选项取得了更大的成功（其中--no-index似乎没有记录）：

git apply --verbose --no-index --directory {subdir} {patch-file}

Answer 4

我根据此处的其他答案整理了一个解决方案，但仍需进行一些研究。这篇文章与其他文章相似，但填补了我在其他文章中遗漏的部分。希望它可以为某人节省一些时间。

就我而言，与源存储库相比，目标存储库中有一个额外的目录级别。换言之，源存储库中的顶级文件夹 source-top-level 包含在目标存储库中的父级 target-top-level 中。但是，由于没有错误，我无法确定这是问题所在。所以我使用了 --verbose，它显示了错误，我可以确认确实是问题所在。

然后我检查了 --directory 选项的 git 文档。它允许您指定一个字符串，该字符串将附加到补丁中每个文件的路径：

--directory=<root>
 Prepend <root> to all filenames.

通过指定 --directory=target-top-level，它将每个路径 source-top-level/some-path 转换为 target-top-level/source-top-level/some-path，这样 git apply 就成功了。

Answer 5

遇到同样的问题。在我的情况下，错误源是补丁目标的某些父目录中的.git文件夹。解决方案是将补丁目标移到父目录之外。

Git应用跳过补丁

5 个答案: