39

我目前正在尝试对（github）存储库的 PR 进行代码样式检查，并且我想向提交者提供补丁，他们可以使用这些补丁轻松修复代码样式。为此，我正在拉下他们的 PR，在其上运行我们的 uncrustify 脚本以修复任何样式错误，并希望创建一个他们可以轻松应用的 .patch 文件。但是，它始终会在某些文件上中断。

我愿意（带有core.autocrlf=input,的 git 版本 1.7.10.4 core.filemode=false）：

$ git checkout pr-branch
$ git log -1 (shows: commit dbb8d3f)
$ git status (nothing to commit, working directory clean)
$ <run the code styler script, which modifies some files>
$ git diff > ../style.patch (so the patch file lands outside the repo)
$ git reset --hard HEAD (to simulate the situation at the submitter's end)
$ git log -1 (shows: commit dbb8d3f)
$ git status (nothing to commit, working directory clean, so we are where we started)
$ git apply ../style.patch
error: patch failed: somefile.cpp:195
error: somefile.cpp: patch does not apply (same output using the --check option)

这仅适用于某些文件，而不是所有文件。我不知道如何解决这个问题，即如何让 git 准确地告诉我哪里出错了——当我挖掘时它只会告诉我一个大块头，但这仍然是相当大的。

到目前为止我尝试过的（没有成功）：

  1. apply --reverse,apply --whitespace=nowarn
  2. diff HEAD而不是一个diff人
  3. 进行虚拟提交（提交工作没有问题！），使用format-patch，删除虚拟提交，应用git-am带有或不带的补丁-3，或应用 git-apply
  4. 将补丁文件放在本地目录而不是一个目录中（抓住稻草，在这里）
  5. 检查 git-diff、-apply、-format-patch、-am 的手册页是否有用
  6. patch用linux命令打补丁
  7. ……

我不知道差异可能有什么问题。空白的东西应该只警告，对吧？在任何情况下，我都不想忽略它们，因为它是一种显然涉及空格的样式修复。

我怎样才能修复/诊断这个，甚至找出它到底在哪里？如果我发布其中一个罪魁祸首文件的差异会有帮助吗？让我感到困惑的是，提交工作没有问题，但从提交创建的补丁却没有？

在与这个搏斗了几个小时之后，我的知识已经走到了尽头......

4

3 回答 3

39

更新：

您可以使用git apply -v来查看有关正在发生的事情的更详细信息，git apply --check仅验证操作或git apply --index重建本地索引文件。

根据您的评论，您的本地索引似乎已损坏，因此index解决了它。

我将留下我最初的答案和评论，主要是为了让人们了解正在发生的事情，因为我怀疑其他人会跳到我根据问题描述得出的相同初步结论。

------

差异很可能没有任何问题。而是查看目标 git 存储库。当你在做的时候git reset --hard HEAD，没有什么能保证你HEAD在那个其他存储库上的 与你的相同HEAD。

在目标 repo 上执行git log并查看顶部的提交。它与您制作差异的那个相同吗？很可能不是。查看历史记录并检查您需要的提交是否存在。如果是，那么目标 repo 就在你之前，你必须回去，做git pull（或git rebase）并产生一个新的差异。如果不是，那么目标 repo 就在您的后面，您需要在目标 repo 上执行git pull（或git rebase）以使其加快速度。

请记住，如果您有其他人提交到您的“主”存储库（您的机器人和目标存储库从中提取的那个），您可能必须同时访问git pull两个存储库，以使它们获得合理的近期共同提交。

于 2013-02-01T15:48:14.567 回答
10

尝试检查您的补丁文件 - 示例：

git apply --reject mypatch.patch

如果有任何差异，这将向您显示差异 - 这是它的外观示例：

error: patch failed: <filename>:<linenumber>
error: while searching for :
    cout << "}" << endl; // example of a line in your patch
于 2016-11-18T12:09:11.990 回答
0

在这种情况下，如果您已经尝试了下面列出的所有选项：

  1. 调查文件中潜在的不可打印/不可见字符
  2. 用于dos2unix转换
  3. 更改 git 配置以调整处理行尾的方式，例如：
git config --global core.autocrlf input

在这种情况下，另一个邪恶的根源可能是您的 IDE。

例如，像 PHPStorm 这样的一些 JetBrains IDE 具有以下选项：

在此处输入图像描述

今天在一个奇怪的补丁问题上花费了超过 4 个血腥小时后，最终出现以下错误：

git apply < my.git.patch --verbose
...
error: patch failed: plugins/some/file.php:74

我意识到我是我的编辑器的受害者（我不确定这是否是默认行为）。

我正在使用 PHPStorm 检查补丁文件，它默默地从补丁文件中删除了一个空格，该空格实际上存在于需要修补的目标文件中。

这是超级偷偷摸摸的，我最终设置了不再遇到此类问题的Strip trailing spaces on Save for选项。None

还要记住，与平台相关的差异，如底层文件系统（例如 MacOS/Linux）的区分大小写也可能是问题所在。

于 2020-06-17T16:17:12.810 回答