Re: [BUG] [RESOLVED] merge-recursive call in git-am -3 chokes, autocrlf issue?

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 1, 2010, 17:27 UTC
Message-ID: <7vbpe3qe09.fsf@alter.siamese.dyndns.org>
In-Reply-To: <hp2jkj$mu0$1@dough.gmane.org>

"Scott R. Godin" <scottg.wp-hackers@mhg2.com> writes:

Show 7 quoted lines

> So my recommendation at this point is to patch the instructions within
> setgitperms.perl to add 'git update-index --refresh' to the end of the
> post-checkout hook.
>
> I've since reset git-am to use recursive again (instead of resolve)
> and done several rebases (both with and without -i) and all seems well
> and normal, and this has made my day.

Ahh. If you muck with work tree files and the index in pre-commit, post-merge, or post-checkout hook (especially if you make an up-to-date work tree file stat-dirty), I can imagine that you would need to "refresh" so that unchanged paths would appear unchanged in the index not to confuse your caller.

I however think the patch probably "fixes" the issue at the worst point. Wouldn't either of these alternatives be better?

 (1) Perhaps the caller of "pre-commit/post-merge/post-checkout" hook
     should instead refresh the index when the hook returns, _iff_ we
     expect that majority of these hooks are used to munge the work tree
     or the index; or

 (2) Because you already established that setgitperms script is the
     culprit that leaves the index unrefreshed, instead of forcing all the
     callers of the script, it should do the refresh for its callers
     before it exits.