On Tue, Jun 26, 2012 at 2:04 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > 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. I'll buy that. But what should we be inspecting the files for? What indicates the conflicts are resolved if not 'git add/rm'? Meanwhile, I run into this trouble when I get a conflicted git-stash-pop. The first thing I do is invoke git-mergetool. This fails with "No files need merging" in the case of a GIT_DIR/MERGE_RR leave-behind from some previous activity. This is quite itchy, and so I am looking for the correct thing to do. Does the MERGE_RR file need to be deleted more often? Do we need some extensible way to indicate currently-unresolved files? Or something in-between these two? P -- 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