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

[Andrew Suffield]

On Wed, Dec 10, 2003 at 10:58:33AM -0800, Tom Lord wrote:
>     > From: Andrew Suffield <address@hidden>
> 
>     [status of design effort for a pure-merge command]
> 
> Give up and take a different tack.   A true pure-merge command (absent
> fancy conflictful commit support) is impossible.

[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. This question arose while sketching out some complicated patch
queue manager ideas. The idea is to precompute possible merges so we
can dispatch them in constant time on demand. Imagine an interface
that showed you the list of changesets that are pending for merge, and
could tell you which combinations work and which don't, all the way
down to the test suite results - I think it's actually computationally
feasible.

Back to the subject at hand.]

> If we skip all of those when idempotently merging, then we have relied
> on the user who made R2 by resolving-by-hand conflicts in C1[R1] to
> have not made any other changes at the same time which _should_ be
> merged.
> 
> In other words, the perfect pure merge command is supposed to spare
> users from having to make very disciplined by-hand resolutions -- but
> you proposal doesn't achieve that.

Not quite. It's supposed to shift the burden from the person applying
the changeset to the person committing the changeset. Obviously
*somebody* is going to have to put the boundaries in the right place,
or idempotent merges are impossible. The idea is to make it as
painless as possible.

> 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.

We're already pretty sure that no merge operator can handle every
possible case. The trick is to detect the cases you can't handle and
fail neatly, and pure-merge should be able to detect such problems
automatically.

You still have the problem of "When I am doing a second-degree merge
from two branches which have both merged the same changeset *and
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.

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

signature.asc
Description: Digital signature