On Tue, Jun 26, 2012 at 12:00 PM, Phil Hord <phil.hord@xxxxxxxxx> wrote: > 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. > > [1]Does the MERGE_RR file need to be deleted more often? > [2]Do we need some extensible way to indicate currently-unresolved files? > Or something in-between these two? > > P >From a mergetool perspective, just doing #2 would be nice. We can have a "default" unmerged files provider that does the `test -s .../MERGE_RR` check since that would probably deal with this ugly edge case. We can then teach this default thing to be smarter and skip text files with no merge markers. Junio, is this what you were thinking? This sounds like a nice way to me. -- David -- 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