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

[Junio C Hamano <gitster@pobox.com>]

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

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

Intuitively, it feels wrong to run "rerere clear" after an operation
that potentially can create conflicts in the index and in the
working tree.

The point in the codepath where the above "git rerere" appears is
immediately after we run merge-recursive backend.  Because the
backend does not invoke rerere itself (which by the way probably is
the correct thing not to; I haven't thought things through, though),
we invoke it ourselves there, so that the user can ask rerere to
replay an earlier conflict resolution.  Why can it be a good thing
to discard potentially useful information with "git rerere clear"?

I just tried this sequence (manually without any patch).

    $ git init empty && cd empty
    $ for i in a b c d e; do echo $i; done >file
    $ git add file && git commit -m initial
    $ for i in a b C d e; do echo $i; done >file ;# c to C
    $ git stash

    $ for i in a B c d e; do echo $i; done >file ;# b to B
    $ git commit -a -m second

    $ mkdir .git/rr-cache ;# enable rerere
    $ git stash apply ;# conflicts
    $ git rerere ;# records preimage

    $ for i in a B C d e; do echo $i; done >file ;# c to C
    $ git commit -a -m third ;# records resolution
    $ git reset --hard HEAD^

    $ git stash apply ;# conflicts
    $ git rerere ;# replays

I think the above "how about this" patch is equivalent to the two
"git rerere" invocations I made manually with my experiment, and it
seems to improve the end user experience (please try it yourself).

What am I missing???