Re: Multi-ancestor read-tree notes

From: Junio C Hamano <junkio@cox.net>
Date: Sep 6, 2005, 05:42 UTC
Message-ID: <7virxeycod.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <Pine.LNX.4.63.0509050049030.23242@iabervon.org>

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.

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

Show 12 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 ;-).