git-apply 神秘地失败了，我该如何排除故障/修复？

git-apply fails mysteriously, how do I troubleshoot/fix?

提问by Christoph

I'm currently trying to to code-style checking on the PRs of a (github) repository, and I want to deliver patches to the submitters with which they can easily fix the codestyle. To this end, I'm pulling down their PR, run our uncrustify script over it to fix any style errors, and want to create a .patch file they can easily apply. However, it consistently breaks on some files.

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

I do (git version 1.7.10.4 with core.autocrlf=input, core.filemode=false):

我这样做（git 版本 1.7.10.4 带有core.autocrlf=input, 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)

This only applies to some files, not all of them. I don't know how to troubleshoot this, i.e. how to get git to tell me exactly where it goes wrong - it only tells me a hunk# when I dig, but that's still pretty huge.

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

What I've tried so far (without success):

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

1. apply --reverse, apply --whitespace=nowarn
2. diff HEADinstead of diffalone
3. make a dummy commit (committing works without problem!), use format-patch, delete the dummy commit, apply patch with git-amwith or without -3, or apply with git-apply
4. Have the patch file in the local dir instead of one up (grasping at straws, here)
5. Check the man-pages of git-diff, -apply, -format-patch, -am for anything useful
6. patch with the linux patchcommand
7. ....

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. 使用 linuxpatch命令打补丁
7. ....

I don't know what could be wrong with the diff. Whitespace things should only warn, right? In any case, I won't want to ignore them, since it's a style fix which obviously involves whitespace.

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

How can I fix/diagnose this or even find out where it bails exactly? Would it help if I posted the diff of one of the culprit files? What baffles me also is that the committ works without problem, but the patch created from the commit does not??

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

After wrestling with this for several hours I'm at the end of my knowledge...

在与这个搏斗了几个小时之后，我的知识已经结束了......

回答by Franci Penov

Update:

更新：

You can use git apply -vto see more detailed info about what's going on, git apply --checkto just verify the operation, or git apply --indexto rebuild the local index file.

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

Based on your comment, it seems your local index was corrupted, and so indexsolved it.

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

I will leave my original answer and the comments mostly to give people context on what was going on, as I suspect other people would jump to the same initial conclusions I had based on the problem description.

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

------

------

Most likely nothing's wrong with the diff. Instead look at the target git repository. While you are doing git reset --hard HEAD, nothing guarantees you that the HEADon that other repository is the same as the HEADon your.

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

Do git logon the target repo and look at the commit at the top. Is it the same as the one you produced the diff from? Most likely it is not. Look down the history and check if the commit you need is there. If it is, then the target repo is ahead of yours, and you have to go back, do git pull(or git rebase) and produce a new diff. If it isn't, then the target repo is behind yours, and you need to do git pull(or git rebase) on the target repo to bring it up to speed.

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

Keep in mind that if you have other people committing to your "master" repo (the one where bot yours and the target repositories are pulling from), you might have to git pullboth repositories, to get them to a reasonably recent common commit.

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

回答by serup

Try to check against your patch file - example :

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

git apply --reject mypatch.patch

this will show you differences if any - here is an example of how it could look like :

这将向您显示差异（如果有）-这是一个示例，说明它的外观：

error: patch failed: <filename>:<linenumber>
error: while searching for :
    cout << "}" << endl; // example of a line in your patch