Re: [Gnu-arch-users] Star merging with 3 branches

[Tom Lord]

    > From: Joshua Haberman <address@hidden>

    > From the way you describe it, it sounds like the problem [of
    > random-topology merging] could be completely avoided by adopting
    > a discipline of never making any manual changes when committing
    > a merge; any desired changes to the merged changes should be
    > committed as a separate changeset.  This does not remove any
    > expressive capability from arch, it just requires merges to be
    > broken into two steps.

That's correct.   The devil is in the details, however.

In the general case, merges can have conflicts and, absent "new
mechanisms", you shouldn't commit while conflicts persist.   Resolving
conflicts runs against the discipline you are suggesting.

Rob Collins has been exploring and using a tool that, as I understand
it, just ignores that issue -- perhaps he can speak about that.   I'm
not sure whether his approach is simply to "not permit conflictful
merges" or "trust the user that the resolution of conflicts doesn't
_really_ count as a change".

A _slightly_ heavier-weight approach that has been discussed in the
past is to permit commits with conflicts present, preserving a record
of the conflicts along with the commit.   If you merge into a tree
that already contains conflicts, and new conflicts result, then the
two sets of conflicts should somehow "compose" in a useful way.

If we do that, then we can implement a 100% robust "pure-merge" that
enforces the discipline you're talking about.

Even better than that:  let's say you have a "hard merge" to do with
many, many conflicts -- if you can commit your conflictful tree, then
you can use revision control to have a whole _team_ of people work on
resolving those conflicts.

The only catch is that handling such "conflictful commits" is a small
research problem -- a few months, I'd say -- and so nobody has yet had
the time to sit down, think it out, and make it so.  (If you come up
with some "hey, that's easy: just ______" solution, I'll give you a
big kiss :-) But my best thinking so far is that it requires a little
bit of new smarts in patch(1) and possibly diff(1) -- not to mention
what it will take in the tree-delta support that arch handles
internally.)


    > Are either of these statements true?

    > 1. Adhering to the discipline I have described allows the algorithm I
    > described (apparently called pure-merge) to handle all cases that
    > star-merge can handle.

That's "pretty much" true.  It's true enough to make a "soft policy"
of if you're willing to problem solve when cases arise that that the
policy doesn't cover.

There are some subtleties that can arise in terms of interaction with
other commands like `replay' but mostly those are just noise.  Yes, if
you can stick to that discipline, then star-merge is nothing more than
(at most) a performance optimization for a subset of the cases you can
handle.

In general -- the more you can organize your project's practices
around managing changesets explicitly and carefully, the more arch
will reward you.   The stuff you're talking about is a particularly
prominent example.


    > 2. Adhering to this discipline will give pure-merge the capability to
    > cover cases that star-merge cannot, such as the situation the original
    > poster described.

That's right.  The only reason that pure-merge isn't part of the core
yet is because the discipline as stated _can_not_ be adhered to in the
general case.  If we had support for either conflictful commits and
merges (as described above) or possibly for some alternative ideas
that have come up ("retroactive conflict resolution factoring" is a
good enough generic name for them), then pure-merge would be front and
center and star-merge would be a "pre-industrial-age" tool.


    > Especially if (2) is correct, this discipline seems to be one that is
    > well worth adopting.  It is not oppressive, it just requires an extra
    > commit before making changes to a merge.  

Other than the nagging issue of merges that have conflicts, that's true.

    > The only problem I can imagine is if you are forcing every
    > revision to pass a test suite or fulfill some other criteria
    > that the merge alone may not fulfill.

Well, you didn't imagine conflicts.  You're correct, though, that the
perfect pure-merge would have to interact with things like automated
acceptence criterea in a thoughtful (but quite doable) way.

Please don't take this as condescending 'cause I mean it in just the
opposite way: congratulations -- you've reached the intellectual
frontier of revision control (to the best of my knowledge)!

-t