Re: [Gnu-arch-users] pure-merge is impossible (was Re: Star merging with 3 branches)

[Andrew Suffield]

On Thu, Dec 11, 2003 at 10:10:17AM -0800, Tom Lord wrote:
>     > From: Andrew Suffield <address@hidden>
> 
>     > [Technically, pure-merge *is* a different tack. The whole pure
>     > changeset thing is really the solution to this problem:
> 
>     > "If I want to construct all the permutations of a group of changesets
>     > applied sequentially, how can I do this without consuming ridiculous
>     > amounts of disk space?"
> 
>     > And the trick about splitting out conflicts is an offshoot of
>     > that. 
> 
> I don't know if we're just talking past each other or not.

Just a little background on how we got to this point. (I don't really
have time to get into that discussion right now, unfortunately)

>     > > In fact we might as well forget about C2, C3, R2pre, and R2mid
>     > > entirely and just let the user commit R2 as the successor to R1 using
>     > > an ordinary commit (perhaps adding a log header to assert "yes, I was
>     > > really careful -- this is a pure merge").  Those intermediate
>     > > revisions don't buy anything here at all.
> 
>     > What they buy you is simplicity in the rest of the code, more or
>     > less. Assuming that conflicts are rare, this reduces them to a problem
>     > that we can easily solve (and have already solved). There are plenty
>     > of other approaches that will have the same effect - the point about
>     > this one is that it's easy.
> 
> I just don't see how C2 and C3 simplify anything or reduce the problem
> of dealing with conflicts.   You create these things and then never
> use them for anything.   Why bother with them at all?

The interesting changeset is C1. We create C2 and C3, occasionally,
because we can't merge C1 directly (they should be small and
rare). The bulk of the change should usually be in the pure changeset,
so the usual algorithm applies.

Again, you could do something similar by bundling all three into one
changeset and tagging at as being a near-clone of the
original. However, you can't now easily distinguish between pure
merges and mixed changesets (unless you compute the whole set and then
recombine them - but recombining them is unnecessary and we might
be able to do interesting things with the components later).

>     > You still have the problem of "When I am doing a second-degree merge
>     > =66rom two branches which have both merged the same changeset *and
        ^^^
Mimefuck!

>     > resolved the conflicts differently*, what do I do?". Your example
>     > appears to be a close variation on that problem.
> 
>     > My current answer is "stop and throw a conflict". I can't think of
>     > anything that any merge operator could usefully do here; the nice
>     > thing about pure merge is that it always knows when to stop, and it
>     > can tell you precisely what is wrong.
> 
> Sure, weak pure-merge sometimes throws up its hands and says "can't be
> done -- try some other technique".    Still don't see what C2 and C3
> are for :-)

That's what they're for - we can easily spot C2/C3 pairs that are
different from the ones already applied for the same C1 changeset. We
couldn't do that if they were always mixed in (unless we encode the
extra data in the mixed changeset, but that seems an unnecessarily
complicated way to achieve the same thing, and requires modifying
tla - as described, pure-merge can be implemented as a wrapper).

There are plenty of other ways to accomplish this, but I haven't seen
any which are as easy to implement.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'                          |
   `-             -><-          |

signature.asc
Description: Digital signature