What to do if git-am fails with "does not match index"?

Question

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:

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.

What's the best way to fix this? Manually change the indexes to match? Or should I git-apply and then copy the author and description information when I commit?

Answer 1

From J.C. Hamano (Git maintainer) himself, this is about:

patch applications and merges in a dirty work tree with a clean index.

• A dirty work tree is 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 index is where you have changes already added to it (in other words, "git diff --cached" will report some changes).
  A clean index matches the HEAD.

With recent Git release, you can abort:

To restore the original branch and stop patching run "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 stash pop

---

Note: one source of dirty tree can be the autocrlf setting (like in this msysgit issue 81), so make sure to set that to false.
Other source of discrepancy: core.whitespace setting.

---

The OP mentions in the comment:

Before trying to run git am I did run git stash, so I don't think that was the problem.
What I ended up doing was running git am -3 patch.patch, then manually fixing the problem, then running 'git am --resolved'.

Note: in the recent 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.

Answer 2

for me i'm on an older versions of git (centOS-6 distro).

I was able to fix the issue by doing:

• git update-index --refresh
• git 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 ;-)

It is sensible to refresh once at the beginning and also when restarting with "am --resolved".

"