[darcs-users] Make darcs force-commute patches from CLI, to learn about darcs?

[Ben Franksen]

Am 29.06.20 um 19:12 schrieb James Cook:
>> Another problem is that even supposing commutation does not change prim
>> patches, in darcs you still have conflictors. And conflictors
>> /definitely/ have to change representation when we commute them: the
>> merge-commute law obviously requires that.
> 
> Could the conflictors be re-computed?

Yes, of course. This is the beauty of patch commutation.

> In more detail: Suppose we've managed to make it so primitive patches
> never change representation. I tell you I built my repo by pulling the
> primitive patches A, B and C in some arbitrary order, changing them
> into conflictors when necessary. (I might also have done some other
> operations, like adding and later obliterating patches, or commuting
> things.) I also tell you that the final order of patches in my repo is
> AB'C', where B' is either B itself or a conflictor keeping B's
> identity (and same for C'). Could there ever be more than one possible
> answer for what B' and C' end up being?

Not if the system maintains all global invariants. Any two sequences of
patches which contain the (nominally) same patches must be
representationally equal after commuting them to the same order.

> If not, doesn't that mean that
> the identities of A, B and C are enough to verify we've got the same
> repo?

Yes, but how does that help us to avoid changing the representation of
conflictors? If you have conflicting patches A and B then the only way
to apply them in you local repo is by choosing an order, say first A
then B. Then B is conflicted and it necessarily behaves differently
compared to a situation where you do not have A in the context.

>>> In theory, you could
>>> even allow plugins that implement new patch types, with the basic
>>> principle that patches communicate with each other through
>>> modifications to the repo metadata.
>>
>> That may be possible, especially for a completely new project that is
>> designed around these notions from the start.
> 
> Sorry to extend this tangent even further (if you keep responding to
> my emails, I'll likely keep sending them :-P),

That's okay. I find the discussion interesting.

> but I had another
> thought: you don't actually need to store the metadata with the repo
> state. You could instead put some metadata into the patches, and allow
> patches to modify each others' metadata when they try to commute.
> Well, at least I think it would work... let me know if you want
> details.

I fail to see the essential difference to what Darcs does now. You just
shift information from the actual patch content to what you (vaguely)
call "meta-data". Then you modify that "meta-data" during commute,
instead of directly modifying the patch content.

Can't you make it a bit more concrete? Use a simple example of two
conflicting (primitive) patches and explain what the meta data looks
like and how the mechanics of commute and merge are supposed to work in
that example and how these patches are applied in sequence.

Cheers
Ben