From: David Brown Date: Wed, 10 Oct 2007 15:48:31 GMT Subject: Re: inexplicable failure to merge recursively across cherry-picks Message-ID: <20071010154831.GA19226@old.davidb.org> In-Reply-To: On Wed, Oct 10, 2007 at 08:25:15AM -0700, Linus Torvalds wrote: >Yes, *some* SCM's have tried to do that. In particular, the ones that are >"patch-based" tend to think that patches are "identical" regardless of >where they are, and while re-ordering of them is a special event, it's not >somethign that changes the fundamental 'ID' of the patch. > >For example, I think the darcs "patch algebra" works that way. > >It's a really horrible model. Not only doesn't it scale, but it leads to >various very strange linkages between patches, and it fails the most >important part: it means that merges get different results just because >people are doing the same changes two different ways. Actually, specifically darcs, different merges _always_ result in the same data. It's a fundamental part of is patch algebra. No matter what order you apply a given set of patches, even with conflicts and reordering, you always get the same result, or no result. Conflicts are "resolved" by inserting conflict markers in the file, ordered by the patch ID. It doesn't matter which order you apply them in, you get the same markers. Then there will be a merge patch which fixes the markers that someone could apply, no matter what order the applied the previous patches. Darcs breaks down in a few places, though. - The no result. Sometimes, it just can't figure out how to reorder patches. Even worse, occasionally, the implementation will fail to terminate try to figure this out. There isn't much to do at this point, except manually apply the patch, hence generating a new patch ID. - It doesn't scale well. The strange linkages between patches could be thought of as a feature, since it is basically constraining the order that the patches can be applied in. There is a darcs-git project that tries to do the darcs things on top of git. Dave