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

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Dec 6, 2006, 10:47 UTC
Message-ID: <Pine.LNX.4.63.0612061145220.28348@wbgn013.biozentrum.uni-wuerzburg.de>
In-Reply-To: <7vlkll72no.fsf@assigned-by-dhcp.cox.net>

Hi,

On Wed, 6 Dec 2006, Junio C Hamano wrote:

Show 14 quoted lines

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

Yes, this was also my thinking. But notice how git-merge-one-file does much more than just merge? So, you end up rewriting it in C anyway, if you want to make merge-index not fork unless "-o cmd" is passed.

Show 6 quoted lines

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

Actually, I just did that. I will add some test cases (to reflect your option (3) in another thread), and submit.

Ciao, Dscho