From: Daniel Barkalow Date: Wed, 07 Sep 2005 18:33:42 GMT Subject: Re: [PATCH 0/2] A new merge algorithm, take 3 Message-ID: In-Reply-To: <20050907164734.GA20198@c165.ib.student.liu.se> On Wed, 7 Sep 2005, Fredrik Kuivinen wrote: > Of the 500 merge commits that currently exists in the kernel > repository 19 produces non-clean merges with git-merge-script. The > four merge cases listed in > <20050827014009.GB18880@c165.ib.student.liu.se> are cleanly merged by > git-merge-script. Every merge commit which is cleanly merged by > git-resolve-script is also cleanly merged by git-merge-script, > furthermore the results are identical. There are currently two merges > in the kernel repository which are not cleanly merged by > git-resolve-script but are cleanly merged by git-merge-script. If you use my read-tree and change git-resolve-script to pass all of the ancestors to it, how does it do? I expect you'll still be slightly ahead, because we don't (yet) have content merge with multiple ancestors. You should also check the merge that Tony Luck reported, which undid a revert, as well as the one that Len Brown reported around the same time which had similar problems. I think maintainer trees are a much better test for a merge algorithm, because the kernel repository is relatively linear, while maintainers tend more to merge things back and forth. -Daniel *This .sig left intentionally blank*