如果git-am失败并显示“不匹配索引”，该怎么办？

Question

我正在尝试应用由其他git-format-patch用户创建的git补丁。补丁是针对HEAD后面的一次提交而做的，但据我所知，这不应该有什么关系。当我运行git am 0001.patch时，我得到以下错误：

error: source.c: does not match index

我不太熟悉git补丁的格式，但是看起来索引并不匹配，但是源代码却是匹配的。

解决这个问题的最好方法是什么？是否手动更改索引以进行匹配？或者我应该提交( git-apply )，然后在提交时复制作者和描述信息？

Answer 1

在J.C. Hamano (Git maintainer) himself中，这是关于：

补丁应用程序和合并在一个干净的索引的脏工作树中。

• A 脏工作树是您具有未添加到索引中的更改的位置。

不脏的工作树是干净的工作树。

• A脏索引是您已向其添加更改的位置(换句话说，"git diff --cached“将报告某些更改)。

与HEAD.匹配的干净索引

使用最新的Git版本，您可以中止：

要恢复原始分支并停止修补，请运行"git am --abort“。

然后：

对于那些无法决定的人来说，最简单的事情可能是将更改隐藏起来，以便以后使用。

$ git stash save "Random changes that are not ready"

，然后重做"git pull“或"git am”。

对于害怕承诺的人来说，"**git stash**“是一个终极工具。

在重做"git pull“或"git am”之后，您可以重放您隐藏的本地更改：

$ git stash pop

注意:脏树的一个来源可以是autocrlf设置(就像在这个msysgit issue 81中一样)，所以使用sure to set that to false。

其他差异来源：core.whitespace setting。

OP在评论中提到：

在尝试运行git am之前，我确实运行了git stash，所以我不认为这是问题所在。

我最终做的是运行git am -3 patch.patch，，然后手动修复问题，然后运行'git am --resolved‘。

注意:在最近的Git1.7.2 Release Notes中

当冲突解决方案最终导致补丁无法运行时，来自"git am -3“的消息已得到改进。

Answer 2

对我来说，我使用的是旧版本的git (centOS-6发行版)。

我能够通过执行以下操作来解决此问题：

• git update-index --refresh
• git am ${patch_filename}

阅读更多关于为什么这样做的文章。请查看the original source here

“

我有点惊讶的是，我们还没有完成“一次刷新”，而且在过去的5年里没有人遇到过这种情况。似乎我从git-applymbox继承了这种行为;-)

明智的做法是在开始时刷新一次，在使用"am --resolved“重新启动时也是如此。

“