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

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

[Zemacsh]

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

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

[Jeff King]

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

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

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

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

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

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

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

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

[Jeff King]

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

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

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

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(-)

diff --git a/git-am.sh b/git-am.sh
index 463c741..6592424 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -511,6 +511,8 @@ else
 	fi
 fi
 
+git update-index -q --refresh
+
 case "$resolved" in
 '')
 	case "$HAS_HEAD" in
-- 
1.7.6.10.g62f04

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

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> ... I wonder if "git rebase" actually
> suffers from the same problem,...

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

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

[Jeff King]

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

> Jeff King <peff@peff.net> writes:
> 
> > ... I wonder if "git rebase" actually
> > suffers from the same problem,...
> 
> Doesn't it require a spiffy clean work tree before even starting?

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

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

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

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

Thanks; applied.