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

> Phil Hord <phil.hord@gmail.com> 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