Subject: Re: [PATCH] merge-recursive: configurable 'merge' program

From: Jakub Narebski <[email-masked]>
Date: Tue, 5 Dec 2006 11:23:32 +0100

Johannes Schindelin wrote:
> 
> On Tue 5 Dec 2006 Jakub Narebski wrote:
> 
>> Sam Vilain wrote:
>> 
>>> For those who like to spawn interactive merge tools on a merge failure
>>> or otherwise run some kind of script allow a "merge.tool" repo-config
>>> option that will take arguments as merge(1) does.
>> 
>> How it goes together with merge-recursive rewrite using built-in merge tool
>> from xdiff xdl_merge?
> 
> Not a big problem. If people like Sam's patch it is easy to integrate 
> since it only means that if merge.tool is set to something non-empty 
> xdl_merge is not called but the merge.tool is forked.

Good idea. By the way, is it replacement for RCS merge, i.e. is it
file-level merge tool, merge.onefile rather than merge.tool? What happens
if there are multiple merge [contents] conflicts: is merge.tool invoked
in parallel for each conflict, or is it waiting for earlier merge.tool
to finish (well, in which case we can always do set merge.tool to 
"<program> &")? And is merge.tool invoked for recursive part of recursive
merge strategy? This merge startegy depended on resolving conflict
markers, i.e. had built-in knowledge of 'merge'/'diff3 -E' output.

Besides, it would be useful not only to spawn interactive merge tools,
but also to use mergers specific for file-type, for example 3DM or xmlcmp
tools for merging XML files.

-- 
Jakub Narebski