Re: git-mergetool: wrap tools with 3 files only to use the BASE file instead of MERGED

[David Aguilar <davvid@gmail.com>]

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