Re: How to extend a patch theory to fully commute

On Fri, Nov 20, 2020 at 06:45:49PM +0100, Ben Franksen wrote:
> Am 20.11.20 um 13:24 schrieb Ben Franksen:
> >> I would like a patch theory where
> >> conflict resolutions are just new patches that replace the conflicting
> >> ones, and don't depend on the patches they're resolving.
> 
> What follows started out as describing a potential problem with this
> idea, but in the end I found that is is easily solvable. The result may
> even be an improvement over what we have today.
> 
> Remember that the actual named patches that the user interacts with
> consist of multiple primitive patches (a "changeset"). Suppose for named
> patches A=(a1;a2) and B=(b1;b2) we have a conflict, but only between a1
> and b1 (this is a pretty typical scenario).

That's a good point. I wonder if it could happen with prim patches alone,
though. Maybe some combination of hunks and substitutions, for example.

> How do we present this at the user level?
> 
> The unresolved conflict is probably presented quite similar to how we do
> it in Darcs now: we tell them that there is a conflict between A and B
> and present the alternatives a1 and b1 as the "content" of the conflict,
> e.g. using conflict markup.
> 
> So far so good. But what about conflict resolution? Suppose the user
> decides that a1 is what they want after all. How do we represent the
> chosen sequence, consisting of
> 
>   A=(a1;a2);B=(b2)
> 
> with a "crippled" B in a sensible way?
> 
> This is just a UI question, but it may be important. For instance, if a
> different user later pushes B to another repo, they may be surprised to
> see that what they push contains more prims than they could see i.e. it
> will be the original B=(b1;b2)!

Although I haven't fully worked it out, the answer I'm leaning toward
is that the deactivation of b1 behaves like a patch (b1 inverse, if you
want to think of it that way). So if your repo has B=(b2), that really
means it has b1,b2,b1^; b1^ probably appears as part of the conflict
resolution patch. When you push your changes, b1^ gets pushed too. There
is no way for b1 to ever become active again, except obliteration of b1^.

I like this point of view because it gives a simple monotone rule about
what happens to each prim when you push: each prim can be in state 0
(not present), 1 (present) or 2 (was present but now deleted), and
merging puts each prim in the max of the two original states (plus
conflict resolution, which is also monotone). This is what I was
thinking in an earlier email when I said I want "inverses on all the
not-chosen branches instead of a flag on the chosen branch" of the
tree.

> This suggests that we should present the "inactive" portions of a named
> patch in a special way e.g. "shaded"or with a bit of extra markup. In
> fact this may be superior to how Darcs operates today, where hitting 'v'
> on a conflictor shows you its internal representation, which isn't too
> helpful.

By hitting v do you mean passing -v to darcs changes? Or am I missing
some cool Darcs UI?

> Cheers
> Ben

-- 
James