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

> 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 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?

> (+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?

> David Aguilar wrote:
> 
> > 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.
> 
> At the risk of taking away the itch for a good feature: meld joined
> the crowd of tools with -o to specify an output file in v1.5.0.
> 
>  http://thread.gmane.org/gmane.comp.gnome.meld.general/1270

> What's the best way to use this and not break existing users?
>
> meld v1.5.0 was released in December.
> We could parse `meld --version` and use the new --output flag on
> newer setups, leaving old setups alone.  That's a lot of
> code to carry around but it's nicest to users.