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

From: Jakub Narebski <jnareb@gmail.com>
Date: Dec 5, 2006, 10:23 UTC
Message-ID: <200612051123.33210.jnareb@gmail.com>
In-Reply-To: <Pine.LNX.4.63.0612050836570.28348@wbgn013.biozentrum.uni-wuerzburg.de>

Johannes Schindelin wrote:

Show 15 quoted lines

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