Re: using xdl_merge(), was Re: Resolving conflicts

[Junio C Hamano <junkio@cox.net>]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> Originally, I thought that building in git-merge-one-file, and enhancing 
> it to recognize by the parameters if it should act as a merge replacement, 
> would be the way to go. Should I do this, or rather add 
> builtin-merge-file?

All in-tree users of git-merge-one-file is of this pattern:

	git merge-index -o git-merge-one-file -a

so I was hoping we can capture this whole thing as a single
command (merge-index would fork+exec a merge-one-file per
unmerged path), instead of doing merge-one-file as a built-in.

In any case, the way your xdl-merge engine is done, it should be
almost trivial to write a pure 'RCS merge replacement' as a
totally separate program -- the bulk of the new code would be
parsing parameters, opening the three input files, populating
mmfile structures and writing the result out, and there would be
almost no "smart" in that part of the code you would want to
share with the git-aware version.