Hi, On Wed, 6 Dec 2006, Junio C Hamano wrote: > Junio C Hamano <junkio@xxxxxxx> writes: > > > Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > > > >> On Tue, 5 Dec 2006, Linus Torvalds wrote: > >> > >>> - take every single merge in git (or the kernel, if you want even more) > > > > The attached is the script I am using. The test checks the > > output from 'master' (merge from RCS) and 'next' (with xdl-merge) > > and also tries to see how different the conflicts look like. > > > > In the git.git archive, there is no "clean" merge on which > > 'master' and 'next' did not agree. It is not a proof of > > correctness at all but it gives a sense of assurance. > > And all merges in linux-2.6.git archive either result in > conflict with both 'merge' implementations, or cleanly resolves > the same way with both 'merge' implementations. I have not > compared the conflicted cases yet, but at least it gives me a > warm fuzzy feeling to see that autocommitted stuff are sensible. Thank you! Slowly I also get a warm fuzzy feeling... My idea, to have an inbuilt work-alike to RCS merge, was not only instigated by my liking the zealous option, but also to be able to add relatively fast tests. 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? 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