git-apply神秘失败，我该如何解决/修复？ [英] git-apply fails mysteriously, how do I troubleshoot/fix?

问题描述

我目前正在尝试对（github）存储库的PR进行代码样式检查，并且我想将修补程序交付给提交者，用它们可以轻松修复代码样式。为此，我拉下了他们的PR，运行我们的uncrustify脚本来修复任何样式错误，并且想要创建一个可以轻松应用的.patch文件。但是，它在一些文件中一直出现问题。

我这样做（git版本1.7.10.4 with core.autocrlf = input ， core.filemode = false ）：
$ b

  $ git checkout pr -branch 
 $ git log -1（显示：commit dbb8d3f）
 $ git status（无需提交，工作目录干净）
 $<运行代码样式化脚本，修改某些文件> ; 
 $ git diff> ../style.patch（所以补丁文件落在回购站之外）
 $ git reset --hard HEAD（模拟提交者端的情况）
 $ git log -1（显示：commit dbb8d3f）
 $ git status（没有提交，工作目录干净，所以我们是我们开始的地方）
 $ git apply ../style.patch 
错误：补丁失败：somefile.cpp ：195 
错误：somefile.cpp：补丁不适用（使用--check选项相同的输出）
  

这仅适用于某些文件，而不适用于所有文件。我不知道如何解决这个问题，也就是说如何让git告诉我它到底发生了什么错误 - 当我挖掘它时，它只会告诉我一个大块头，但仍然非常大。

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

1. apply --reverse ， apply --whitespace = nowarn


2. diff HEAD >而不是 diff 独自
   
3. 做一个虚拟提交（commiting works without problems！），使用 format-patch ，删除伪提交，使用 git-am 应用修补程序（含或不含 -3 ，或申请 git-apply


4. 在本地目录中提供补丁文件，而不是一个（抓住吸管，在这里）


5. 检查git-diff，-apply，-format-patch，-am的手册页以获取任何有用的信息


6. linux patch 命令


7. ....

我不知道差异可能是什么问题。空白的东西只应该警告，对吧？无论如何，我不想忽视它们，因为它是一种明显涉及空白的样式修正。

我该如何修复/诊断，甚至找出在哪里它保证准确？如果我发布了其中一个罪魁祸首文件的差异，会有帮助吗？让我感到困惑的是，这个委托没有任何问题，但是从提交创建的补丁没有这个问题。

经过几个小时的摔跤后，我在结束我的知识...

解决方案

更新：

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

根据你的评论，看起来你的本地索引已损坏，所以 index 解决了它。

我会留下我的原始答案和评论主要是为了让人们了解发生的事情，因为我怀疑其他人会跳到我基于问题描述得出的同样的初步结论。

------

差异很可能没有问题。而是看看目标git存储库。当你在做 git reset --hard HEAD 时，没有什么能保证你在其他仓库的 HEAD 是相同的作为您的 HEAD 。

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

请记住，如果您有其他人对您的主回购（即您的主回购并且目标存储库正在从中提取），那么您可能必须 git pull 这两个存储库，才能使它们成为最近常见的常见提交。

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.

I do (git version 1.7.10.4 with 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.

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

1. apply --reverse, apply --whitespace=nowarn
2. diff HEAD instead of diff alone
3. make a dummy commit (committing works without problem!), use format-patch, delete the dummy commit, apply patch with git-am with 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 patch command
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...

解决方案

Update:

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

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

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 HEAD on that other repository is the same as the HEAD on your.

Do git log on 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.

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 pull both repositories, to get them to a reasonably recent common commit.

这篇关于git-apply神秘失败，我该如何解决/修复？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！