"git apply --check" successes but git am says "does not match index"

Hi, all, 

I met a problem with git am.

Before applying a mbox patch, "git apply --check" reports OK. Then, I run 'git am', however, it complains "does not match index". Actually, both working tree and index are clean. what might be the problem?

If I run "git am --abort" now, and re-turn "git am". To my surprise, everything goes well.

Best

-- zemacsh

On Sun, Aug 14, 2011 at 09:36:30AM +0000, Zemacsh wrote:

Hmm. I don't think this has anything to do with the "apply --check". But rather the problem is that "git am" doesn't ever refresh the index. For example:

  git init repo &&
  cd repo &&
  echo one >file && git add . && git commit -m one &&
  echo two >file && git add . && git commit -m two &&
  git format-patch -1 --stdout >patch &&
  git reset --hard HEAD^ &&
  sleep 1 &&
  touch file &&
  git am patch

This fails with:

  Applying: two
  error: file: does not match index
  Patch failed at 0001 two

Running "git am --abort" resets the index, which freshens it, and then a further "git am" works:

  $ git am --abort
  $ git am patch
  Applying: two

We should perhaps call "update-index --refresh" at the start to avoid these sorts of false positives. Probably it should happen whenever we "git am --continue", as well. But for efficiency reasons, not between each patch.

I dunno. Do people want to call "git am" in a tight loop, where the index refresh would be a problem? I would think they should instead feed a whole mbox in one go.

-Peff

Jeff King <peff@peff.net> writes:

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".

On Mon, Aug 15, 2011 at 04:52:55PM -0700, Junio C Hamano wrote:

It's a pretty rare set of circumstances:

  1. You make a file stat-dirty, but don't actually change its contents.

  2. You don't run any index-refreshing porcelains.

  3. You apply a patch that touches that file.

The patch below does this. I think this makes the "update-index" call in git-rebase.sh:522 redundant when the "am" backend is used. But it is still needed for the other backends. I wonder if "git rebase" actually suffers from the same problem, since it seems to refresh only on --continue, but not at the beginning.

-- >8 --
Subject: [PATCH] am: refresh the index at start and --resolved

If a file is unchanged but stat-dirty, we may erroneously fail to apply patches, thinking that they conflict with a dirty working tree.

This patch adds a call to "update-index --refresh". It comes as late as possible, so that we don't bother with it for thinks like "git rebase --abort", or when mbox-splitting fails. However, it does come before we actually start applying patches, meaning we will only call it once when we start applying patches (or any time we return to "am" after having resolved conflicts), and not once per patch.

Signed-off-by: Jeff King <peff@peff.net>
---
 git-am.sh |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

Jeff King <peff@peff.net> writes:

Doesn't it require a spiffy clean work tree before even starting?

On Mon, Aug 15, 2011 at 09:10:43PM -0700, Junio C Hamano wrote:

Ah, you're right. I was confused that the continue case called update-index, but the regular case did not. But it calls require_clean_work_tree, which refreshes the index (in addition to checking the dirty state, of course). So it's fine.

-Peff

Jeff King <peff@peff.net> writes:

Thanks; applied.