Re: [RFC/PATCH] stash: Delete MERGE_RR before stash apply

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 5, 2012, 17:15 UTC
Message-ID: <7v7guiruxo.fsf@alter.siamese.dyndns.org>
In-Reply-To: <CABURp0pNsRQgbf7_iYc-xVaySa9-gGiA++Lw4-WgSCQ4QGCXsA@mail.gmail.com>

Phil Hord <phil.hord@gmail.com> writes:

Show 8 quoted lines

> The presence of a GIT_DIR/MERGE_RR file indicates we
> were resolving a merge which had rerere candidates for
> recording.  But the file does not get deleted after
> all resolutions are completed.  This is ok for most
> cases because the file will get replaced when the
> next merge happens.  But stash apply does not use
> a merge that supports rerere, and so the old
> MERGE_RR does not get replaced with a current one.

Thanks for digging to the real cause. It does use merge-recursive backend directly, and as a backend, it probably is correct that it does not invoke rerere itself.

In your patch, you are removing the state before you check and notice that the user is in the middle of a merge and give control back with "Cannot apply a stash in the middle of a merge". Wouldn't it be nicer to the user if you didn't remove the rerere state when this happens (i.e. the user mistakenly said "stash apply" after a conflicted merge), as that rerere state likely is from that merge that produced the conflicted state?

Would an obvious alternative of running "git rerere" ourselves after running "git merge-recursive" in this script work?

 git-stash.sh | 1 +
 1 file changed, 1 insertion(+)

diff --git a/git-stash.sh b/git-stash.sh
index 4e2c7f8..bbefdf6 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -469,6 +469,7 @@ apply_stash () {
 	else
 		# Merge conflict; keep the exit status from merge-recursive
 		status=$?
+		git rerere
 		if test -n "$INDEX_OPTION"
 		then
 			gettextln "Index was not unstashed." >&2