Re: [PATCH 0/2] A new merge algorithm, take 3
- From
Daniel Barkalow <barkalow@iabervon.org>
- Date
- Sep 7, 2005, 18:33 UTC
- Message-ID
- <Pine.LNX.4.63.0509071409470.23242@iabervon.org>
- In-Reply-To
- <20050907164734.GA20198@c165.ib.student.liu.se>
On Wed, 7 Sep 2005, Fredrik Kuivinen wrote:
Show 9 quoted lines
> 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*