On Wed, Aug 10, 2011 at 11:12:11AM -0500, Jonathan Nieder wrote: > (+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? I think it sounds like a good thing for certain tools. Sebastian mentioned it being fine in ecmerge and bc3. xxdiff also lets you specify the output file, so it probably wouldn't need it either, I think. If the patch touches individual tools that need it, e.g. meld, I say go for it. > Regards, > Jonathan > > [1] http://bugs.debian.org/637355 cheers, -- 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