Re: inexplicable failure to merge recursively across cherry-picks

[David Brown <git@davidb.org>]

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