Hi, On Wed, 6 Dec 2006, Junio C Hamano wrote: > Johannes Schindelin <Johannes.Schindelin@xxxxxx> 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 - 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