(+cc: some relevant people) Hi, Tanguy Ortolo wrote[1]: > git-mergetool ideally uses tools that work with 4 files: BASE, LOCAL, > REMOTE, which are the usual original and two new version of the file, > and MERGED, which is where the tool is supposed to write the result of > the merge. > > The problem is that most tools, at least graphical ones, specifically > meld, can only work with three files, as they save the result to the > original file. > > git-mergetool currently handles this situation by passing MERGED LOCAL > REMOTE to the tool. This could be fine, but unfortunately MERGE contains > the conflicts, formatted for manual resolution, so it is not really > appropriate as an original file. > > I think it would be better to wrap such merge tools by: > 1. passing them BASE LOCAL REMOTE; > 2. checking whether or not BASE hase been modified: > * if it has, then copying it to MERGED, > * if it has not, exiting with return code 1 (merge failed). > This check can be by either saving and comparing the mdate, or perhaps > the SHA-1 hash of the BASE file. > > If this sounds good enough, I can dive into git-mergetoo--lib and > implement it. In the meantime, here is an example of a custom merge tool > that wraps meld for that purpose. I think you forgot to include the example. Anyway, at first glance it sounds like a sensible idea. David et al: thoughts? Regards, Jonathan [1] http://bugs.debian.org/637355 -- 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