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

[Jeff King <peff@peff.net>]

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