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