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

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Dec 5, 2006, 14:07 UTC
Message-ID: <Pine.LNX.4.63.0612051459380.28348@wbgn013.biozentrum.uni-wuerzburg.de>
In-Reply-To: <200612051123.33210.jnareb@gmail.com>

Hi,

On Tue, 5 Dec 2006, Jakub Narebski wrote:

> By the way, is it [ed: xdl_merge()] replacement for RCS merge, i.e. is 
> it file-level merge tool, merge.onefile rather than merge.tool?

It is a C function, but yes, it does what RCS merge does.

> 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> &")?

Recursively. It is merge-recursive, so the merges are done sequentially. (Have to be, since the result of one merge is reused as one input for the next merge.)

> And is merge.tool invoked for recursive part of recursive merge 
> strategy?

Yes.

> This merge startegy depended on resolving conflict markers, i.e. had 
> built-in knowledge of 'merge'/'diff3 -E' output.

No. git-merge-recursive never resolved conflict markers, but treated them as text.

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

If you need that, write a wrapper script, which detects the file type and execs the corresponding merge program.

Ciao, Dscho