我正在尝试应用由其他人使用git-format-patch 创建的 git 补丁。该补丁是针对 HEAD 背后的一次提交制作的，但据我了解，这无关紧要。当我运行git am 0001.patch 时，我得到了错误：
error: source.c: does not match index
我对 git 补丁的格式不太熟悉，但似乎索引不匹配，但源匹配。
解决此问题的最佳方法是什么？手动更改索引以匹配？还是应该git-apply，然后commit的时候复制作者和描述信息？
【问题讨论】：
来自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”的消息已得到改进。
【讨论】：
git am 之前，我确实运行了git stash，所以我认为这不是问题所在。我最终做的是运行git am -3 patch.patch，然后手动修复问题，然后运行“git am --resolved”。
对我来说，我使用的是旧版本的 git（centOS-6 发行版）。
我能够通过以下方式解决问题：
git update-index --refresh git am ${patch_filename} 阅读更多关于它为什么有效的信息。请查看the original source here:
"
我有点惊讶我们没有“预先刷新一次” 在过去的 5 年里，已经没有人遇到过这种情况。看起来 我从 git-applymbox 继承了这种行为 ;-)
在开始时刷新一次以及在重新启动时刷新一次是明智的 用“我--已解决”。
"
【讨论】：