Re: Multi-ancestor read-tree notes

From: Daniel Barkalow <barkalow@iabervon.org>
Date: Sep 6, 2005, 17:43 UTC
Message-ID: <Pine.LNX.4.63.0509061228090.23242@iabervon.org>
In-Reply-To: <7virxeycod.fsf@assigned-by-dhcp.cox.net>

On Mon, 5 Sep 2005, Junio C Hamano wrote:

Show 25 quoted lines

> Daniel Barkalow <barkalow@iabervon.org> writes:
> 
> > I've got a version of read-tree which accepts multiple ancestors and does 
> > a merge using information from all of them.
> 
> After disabling the debugging printf(), I used this read-tree to
> try resolving the parents of four commits Fredrik Kuivinen gave
> us in <20050827014009.GB18880@c165.ib.student.liu.se> using
> their two merge bases, and compared the resulting tree with the
> tree recorded in the commit.  The results are really promising.
> 
> For the following two commits, multi-base merge resolved their
> parents trivially and produced the same result as the tree in
> the commit.  The current "best-base merge" in the master branch
> performed far worse and left many conflicts.
> 
>  - 467ca22d3371f132ee225a5591a1ed0cd518cb3d 
>  - da28c12089dfcfb8695b6b555cdb8e03dda2b690
> 
> Another one, 0e396ee43e445cb7c215a98da4e76d0ce354d9d7,
> multi-base merge left only one conflicting path to be hand
> resolved.  The best-base merge again performed far worse.
> 
> The other one, 3190186362466658f01b2e354e639378ce07e1a9, is
> resolved trivially with both algorithms.

Do you know if there's anything like case #16 in there? I'd be interested to know if there's anything that gets handled automatically in different ways depending on which single base is used, and doesn't require manual intervention with multiple bases, because that's probably wrong.

Show 8 quoted lines

> > In case #16, I'm not sure what I should produce. I think the best thing 
> > might be to not leave anything in stage 1.
> 
> Because?  I know it would affect the readers of index files if
> you did so, but it would seem the most natural in git
> architecture to have merge-cache look at the resulting cache
> with such multiple stage 1 entries (and other stages) and let
> the script make a decision.

I didn't want to break the assumption of only one entry per stage in the initial version. I'm also not sure that listing the ancestors is particularly useful in this case. They have to be exactly the contents of stages 2 and 3, plus possibly more stuff that's not been kept by either side. What you actually want is a two-way merge (i.e., a diff between the two sides, presented in "merge" format), so you don't really need any ancestors, unless it would fit some more general case that way.

Show 18 quoted lines

> > The desired end effect is that the user is given a file with a
> > section like:
> >
> >   {
> >     *t = NULL;
> >     *m = 0;
> > <<<<<<<<
> >     return Z_DATA_ERROR;
> > ========
> >     return Z_OK;
> >>>>>>>>>
> >   }
> 
> Sounds fine.
> 
> Anyway, I really am happy to see this multi-base merge perform
> well on real-world data, and you are certainly the git hero of
> the week ;-).

Great. Want me to send the patches with better organization, or are you set with what I've sent?

	-Daniel
*This .sig left intentionally blank*