On Thu, Jul 5, 2012 at 1:15 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Phil Hord <phil.hord@xxxxxxxxx> writes: > >> 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. Well, it only took me a year. http://permalink.gmane.org/gmane.comp.version-control.git/177224 > 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 Yes, except it needs "git rerere clear". "git rerere" is not enough to cause the clean-up to occur. I'll roll a patch. Phil -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html