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

[Phil Hord <phil.hord@xxxxxxxxx>]

On Fri, Jul 6, 2012 at 4:01 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Phil Hord <phil.hord@xxxxxxxxx> 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???

I thought the reason rerere was not supported was because of some
limitation in the type of merge being completed.  I didn't think it
was possible to make rerere actually work with this situation.

I understand now.  I'll try again.

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