From: Phil Hord Date: Tue, 26 Jun 2012 19:00:59 GMT Subject: Re: MERGE_RR droppings Message-ID: In-Reply-To: <7v395ic5kq.fsf@alter.siamese.dyndns.org> On Tue, Jun 26, 2012 at 2:04 PM, Junio C Hamano wrote: > Phil Hord 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