Re: MERGE_RR droppings

> Phil Hord <phil.hord@gmail.com> writes:
>
>> git mergetool decides to use rerere-remaining based on the existence
>> of the .git/MERGE_RR file:
>>
>>     if test -e "$GIT_DIR/MERGE_RR"
>>     then
>>         files=$(git rerere remaining)
>>     else
>>         files=$(git ls-files -u | sed -e 's/^[^ ]*      //' | sort -u)
>>     fi
>>
>> But when I disabled rerere, I still had MERGE_RR files left over in my
>> .git directory.   This causes git-mergetool to do the wrong thing.
>>
>> I do not know if the correct fix for this is to check rerere.enabled instead.
>
> I do not think basing the decision to use "ls-files -u" output upon
> the use of "rerere" is a good thing for this script to do in the
> first place.  Doesn't it close the door to future enhancements and
> third-party mechanisms that do better job than rerere to help the
> users auto-resolve conflicted merges?  They certainly do not have to
> use GIT_DIR/MERGE_RR nor GIT_DIR/rr-cache, and "rerere remaining"
> would not know which paths they handled already.
>
> After all, the user may have resolved the conflicts in his editor
> but hasn't recorded the resolution to the index yet when he runs
> mergetool, and the tool should handle such a path exactly like how
> it currently handles the paths resolved by rerere in the working
> tree.  But the above code will include such paths in the $files list
> and throw them at the mergetool backends when rerere is not in use.
>
> This part of the code probably should be _inspecting_ the files and
> the index to find out what still needs to be fed to the mergetools
> itself.  Asking "rerere remaining" about things that it may not have
> done (either the user edited the paths in the editor, or some
> third-party mechanism resolved the conflicts already) does not make
> much sense, methinks.