我正在尝试使用git-format-patch应用其他人创建的git补丁。该补丁是针对HEAD背后的一个提交而制作的，但据我所知，这应该无关紧要。当我运行git am 0001.patch时，我收到错误：
error: source.c: does not match index
我不太熟悉git补丁的格式，但似乎索引不匹配，但源确实匹配。
解决此问题的最佳方法是什么？手动更改索引以匹配？或者我应该git-apply然后在我提交时复制作者和描述信息？
答案 0 :(得分：12)
来自J.C. Hamano (Git maintainer) himself，这是关于：
修补应用程序并在具有干净索引的脏工作树中进行合并。
- 脏工作树是您没有添加到索引的更改的地方 不脏的工作树是一个干净的工作树。
- 脏索引是您已添加更改的位置（换句话说，“
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”的消息得到了改进。
答案 1 :(得分：1)
对我来说，我使用的是较旧版本的git（centOS-6发行版）。
我能够通过以下方式解决问题：
git update-index --refresh git am ${patch_filename} 详细了解其原因。请查看the original source here：
“
我很惊讶我们还没有完成“先刷新一次” 已经没有人在过去的5年中遇到过这种情况。看起来 我从git-applymbox继承了这种行为;-)
在开始时和重新启动时刷新一次是明智的 与“我 - 解决”。
“