On Tue, Feb 24, 2009 at 03:32:50AM -0500, Caleb Cushing wrote: > On Tue, Feb 24, 2009 at 2:47 AM, Charles Bailey <charles@xxxxxxxxxxxxx> wrote: > > I'll look at adding > > a test case to mergetool and see how easy it is to get it to handle > > this case better. > > few weeks back I created a patch for mergetool, it was rejected > ultimately on the basis that it had to cleanup temporary files and in > reality this was a problem with a lot of mergetool, the suggestion was > made that mergetool needs refactoring. I believe this problem is a > similar symptom. basically mergetool should touch my files before I > tell it what to do. if it has to move and back up my files before > deciding then at the very least it should copy them back into place if > I delete the remote. preferably in this case though it would just > delete the remote or backup my local files and copy the remote in > after I told it what to do (or maybe even delete my local files). Coincidentally, last night I started looking at a mergetool refactoring but more with unifying the handling of temporaries and actions between the different types of merge (symlink, deleted file and 'normal'). I'm more of the opinion that in any non-trivial case (i.e. not a regular file/file merge), it *shouldn't* do anything until you tell it what you want it to do. Clearly, between a tree and a blob, mergetool is not going to be able to invoke a mergetool on set of three blobs, but it should work out what it can do before prompting for a choice from the user of what they want it to do. -- Charles Bailey http://ccgi.hashpling.plus.com/blog/ -- 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
