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