如果git-am因"索引不匹配"失败怎么办?

jos*_*doe 16 git patch

我正在尝试应用由其他人创建的git补丁git-format-patch.该补丁是针对HEAD背后的一个提交而制作的,但据我所知,这应该无关紧要.当我跑git am 0001.patch,我得到错误:

error: source.c: does not match index

我不太熟悉git补丁的格式,但似乎索引不匹配,但源确实匹配.

解决这个问题的最佳方法是什么?手动更改索引以匹配?或者我应该git-apply在提交时复制作者和描述信息吗?

Von*_*onC 19

来自JC Hamano(Git maintainer)本人,这是关于:

修补应用程序并在具有干净索引的脏工作树中进行合并.

  • 一个肮脏的工作,树就是你有没有被添加到指数的变化.
    不脏的工作树是一个干净的工作树.
  • 一个肮脏的指标是你已经加入到它的变化(换句话说," git diff --cached"将报告一些变化).
    干净的索引与HEAD匹配.

随着最近的Git发布,你可以中止:

要恢复原始分支并停止修补运行" git am --abort".

然后:

对于那些无法决定的人来说,最简单的事情可能是将这些变化隐藏起来以备日后使用.

$ git stash save "Random changes that are not ready"
Run Code Online (Sandbox Code Playgroud)

然后重做" git pull"或" git am".
" git stash"是那些害怕承诺的人的终极工具.

重做" git pull"或" git am"之后,您可以重播您隐藏的本地更改:

$ git stash pop
Run Code Online (Sandbox Code Playgroud)

注意:脏树的一个来源可以是autocrlf设置(如在这个msysgit问题81中),因此请确保将其设置为false.
其他差异来源:core.whitespace设定.


OP在评论中提到:

在试图跑之前git am我确实跑了git stash,所以我不认为那是问题所在.
我最终做的是运行git am -3 patch.patch,然后手动修复问题,然后运行' git am --resolved'.

注意:在最近的Git1.7.2发行说明中:

git am -3当冲突解决最终使补丁成为无操作时,来自" " 的消息得到了改进.


Tre*_*ith 5

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

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

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

阅读更多关于为什么这有效。请在此处查看原始来源

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

在开始时刷新一次以及在使用“am --resolved”重新启动时刷新一次是明智的。