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