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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html