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

[James Cook]

> This in turn led me to the more general question of how to detect
> inconsistencies when exchanging patches between repos. The problem here
> is that darcs currently relies on global uniqueness properties that are
> quite easy to invalidate (e.g. by manually editing patches, and as
> hinted above also when we independently convert branches of a repo).
> Specifically, we rely on the following global property: if two patches
> have the same name/identity, then (a) they can always be commuted to a
> common context and (b) they are equal (content-wise) after commuting
> them to any such common context. (The context of a patch is defined as
> the set of patches preceding it.) Effectively this property means that
> patches with the same name/identity are really just commuted/merged
> versions of one and the same original patch.
>
> I have an (efficient) algorithm in mind that validates these assumptions
> whenever we exchange patches between repos. Implementing this requires a
> pretty deep refactor though.

I was wondering if global uniqueness could be solved by borrowing from Pijul.

If you include some metadata as part of the repository state (e.g. the
identity of the hunk responsible for every line of every text file)
then I think you could make it so that a primitive patch's
representation doesn't change when it's commuted. I suspect pretty
much any primitive patch theory could be adapted to work this way.
(Note I'm not claiming this will make everything actually commute like
in Pijul.)

Besides giving unique names, another nice thing about this is that you
shouldn't need to implement n^2 different patch commuting functions
for n types of primitive patch. (I don't know if darcs actually needs
to do this; I'm just assuming.) If you have access to the repo state,
you can tell if two patches commute just by trying to apply them in
the opposite order and seeing if they complain. 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.

A slightly less radical version of this would be to keep the current
primitive patch representation, but use this idea when generating the
patch names. E.g. a hunk's name is a hash involving the identities of
the hunks responsible for the lines it deletes. You'd still need to
keep some metadata around to be able to do that, though.

James