如果 git-am 因“与索引不匹配”而失败怎么办？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/3575712/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
What to do if git-am fails with "does not match index"?
提问by joshdoe
I'm trying to apply a git patch created by someone else with git-format-patch. The patch was made against one commit behind HEAD, but as I understand it this shouldn't matter. When I run git am 0001.patch, I get the error:
我正在尝试应用由其他人创建的 git 补丁git-format-patch。该补丁是针对 HEAD 后面的一次提交制作的，但据我所知，这无关紧要。当我运行时git am 0001.patch，出现错误：
error: source.c: does not match index
error: source.c: does not match index
I'm not too familiar with the format of git patches, but it does seem that the indexes don't match, however the source does match.
我对 git 补丁的格式不太熟悉，但似乎索引不匹配，但是源确实匹配。
What's the best way to fix this? Manually change the indexes to match? Or should I git-applyand then copy the author and description information when I commit?
解决这个问题的最佳方法是什么？手动更改索引以匹配？或者我应该git-apply在提交时复制作者和描述信息？
回答by VonC
From J.C. Hamano (Git maintainer) himself, this is about:
来自JC Hamano（Git 维护者）本人，这是关于：
patch applications and merges in a dirty work tree with a clean index.
- A dirty work treeis where you have changes that are not added to the index.
A work tree that is not dirty is a clean work tree.- A dirty indexis where you have changes already added to it (in other words, "
git diff --cached" will report some changes).
A clean index matches the HEAD.
修补应用程序并在带有干净索引的脏工作树中合并。
- 一个肮脏的工作，树就是你有没有被添加到指数的变化。
不脏的工作树是干净的工作树。- 一个肮脏的指标是你已经加入到它的变化（换句话说，“
git diff --cached”将报告一些变化）。
干净的索引与 HEAD 匹配。
With recent Git release, you can abort:
使用最近的 Git 版本，您可以中止：
To restore the original branch and stop patching run "
git am --abort".
要恢复原始分支并停止修补运行“
git am --abort”。
Then:
然后：
The simplest thing for those who cannot decide may be to stash the changes away for later.
对于那些无法决定的人来说，最简单的事情可能是将更改藏起来以备后用。
$ git stash save "Random changes that are not ready"
And then redo "
git pull" or "git am".
"git stash" is the ultimate tool for people who are afraid of commitment.After redoing "
git pull" or "git am", you can replay the local changes you stashed away:
然后重做“
git pull”或“git am”。
“git stash”是害怕承诺的人的终极工具。重做“
git pull”或“git am”后，您可以重播您隐藏的本地更改：
$ git stash pop
Note: one source of dirty tree can be the autocrlfsetting (like in this msysgit issue 81), so make sure to set that to false.
Other source of discrepancy: core.whitespacesetting.
注意：脏树的一个来源可以是autocrlf设置（如在这个msysgit issue 81 中），因此请确保将其设置为 false。
其他差异来源：core.whitespace设置。
The OP mentions in the comment:
OP 在评论中提到：
Before trying to run
git amI did rungit stash, so I don't think that was the problem.
What I ended up doing was runninggit am -3 patch.patch, then manually fixing the problem, then running 'git am --resolved'.
在尝试运行之前，
git am我确实运行过git stash，所以我认为这不是问题所在。
我最终做的是运行git am -3 patch.patch，然后手动修复问题，然后运行 'git am --resolved'。
Note: in the recent Git1.7.2 Release Notes:
注意：在最近的Git1.7.2 Release Notes 中：
The message from "
git am -3" has been improved when conflict resolution ended up making the patch a no-op.
git am -3当冲突解决最终使补丁成为无操作时，来自“ ”的消息已得到改进。
回答by Trevor Boyd Smith
for me i'm on an older versions of git(centOS-6 distro).
对我来说，我使用的是旧版本的git（centOS-6 发行版）。
I was able to fix the issue by doing:
我能够通过执行以下操作来解决问题：
git update-index --refreshgit am ${patch_filename}
git update-index --refreshgit am ${patch_filename}
to read more on why this works. please check the original source here:
"
”
I am kind of surprised that we have not done the 'refresh once upfront' already and nobody ever run into this for the past 5 years. It seems that I inherited that behaviour from git-applymbox ;-)
我有点惊讶我们还没有完成“预先刷新一次”，而且在过去的 5 年里没有人遇到过这种情况。似乎我从 git-applymbox 继承了这种行为；-)
It is sensible to refresh once at the beginning and also when restarting with "am --resolved".
在开始时刷新一次以及在使用“am --resolved”重新启动时刷新一次是明智的。
"
”
