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

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

Hi,

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

Show 21 quoted lines

> Junio C Hamano <junkio@cox.net> writes:
> 
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> 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