Re: inexplicable failure to merge recursively across cherry-picks
On Wed, Oct 10, 2007 at 08:48:31AM -0700, David Brown <git@davidb.org> wrote:
> 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.
Show 8 quoted lines
> 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.
Show 5 quoted lines
> - 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.
Show 5 quoted lines
> Dave
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Miklos Vajna <vmiklos@frugalware.org>