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

[Tom Lord]

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

Let's suppose that C1 originally comes from branch S:

        S1 ---------> S2
              C1
To purely merge C1 into the R branch you say that we want:

    > In general, we want this:

    >   R1 ------> R2pre ------> R2mid ------> R2
    >        C2            C1            C3

where R2 is created by hand by resolving any conflicts that arise 
when making:

        C1[R1]          (apply C1 to R1)

and you also say that if we then idempotently merge the R1..R2
changes into some branch that already has C1, we want to skip C2, C1,
and C3.

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.

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.

You might instead say that given trees R1 (from the archive) and R2
(created by hand) what we _really_ want is:


        R1 --------> R2_pure_part ---------> R2
             C1'                     C4

so that during an idempotent merge of R1..R2 into some version that
already contains C1, we skip C1' but apply C4.

The problem is that R2_pure_part _can_not_ be computed automatically.
Suppose I give you this problem:


        here are four trees:

        S1      S2
        R1      R2

        where R2 is derived by applying delta(S1, S2) to R1 and
         fixing up conflicts by hand.

        What is R2_pure_part?

Not only is there not a unique answer to "what is R2_pure_part", but 
there are multiple answers which might be correct depending on
externalities that arch can't possibly know.

Suppose, for example, that for a given line in the source code
we see:

        S1:     fn_a (x);
        S2:     fn_b (x);
        R1:     fn_a (x, y);
        R2:     fn_b (x, y);

what should that line be in R2_pure_part?   The most plausible
candidates are:

        a)      fn_a (x);
        b)      fn_a (x, y);
        c)      fn_b (x);
        d)      fn_b (x, y);

The answer determines what changes go in C4:

        a)      - fn_a (x)
                + fn_b (x, y);


        b)      - fn_a (x, y)
                + fn_b (x, y);


        c)      - fn_b (x)
                + fn_b (x, y);


        d)      <no change>


and any one of those answers might be the right one, depending on what
else is going on.   Not only might any one of those be the right
answer: _which_one_ is the right answer depends partly on what you're
idempotently merging into!

So in effect, _at_best_, the user has to explicitly create
R2_pure_part and that brings us full circle: the user may as well have
created R2_pure_part instead of R2 in the first place, committed that
(perhaps with the extra log header saying "I was really careful, I
promise"), and then went on to make R2 in a separate commit.

Since no tool can possibly automatically answer the above multiple
choice question about R2_pure_part, a reliable and general pure-merge
command is impossible.

-t