From: Johannes Schindelin Date: Wed, 06 Dec 2006 10:47:25 GMT Subject: Re: using xdl_merge(), was Re: Resolving conflicts Message-ID: In-Reply-To: <7vlkll72no.fsf@assigned-by-dhcp.cox.net> Hi, On Wed, 6 Dec 2006, Junio C Hamano wrote: > Johannes Schindelin 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. > 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