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