So here's the thing: "merge by value" is unsound. If duplicate prim patches
do not have an identity, then permutivity goes down the drains.
I wonder how I wasn't able to see this before; it's really simple.
Here is the basic example: we have two repos, in one we have a patch p1, in
the other we have p2:>q (which do not commute) and p1 and p2 are duplicates
i.e. they make the same primitive change. We merge them one way and get
p1:>p2:>q, where the names here are supposed to identify patch identity, not
content, so they are invariant under merging and commutation. So now q
depends on either p1 or p2. That means we can commute
(1) p1:>p2:>q <> p1:>q:>p2
because the conflicting patches always commute. But we cannot commute p1:>q
here because q depends on one of p1 or p2. On the other hand we can commute
p1 and p2 (they directly conflict), so we have
(1) p1:>p2:>q <> p2:>p1:>q
But to the q conflictor p1 and p2 look exactly the same, so with the same
argument as above we can commute
(2) p2:>p1:>q <> p2:>q:>p1
(which is also the same as merging the two repos in the other direction).
So p1:>q commutes if preceded by p2, but not if we commute p2 past both, in
direct contradiction to permutivity.
This has assumed that duplicate patches conflict as they do in darcs1
format. In darcs2 we get a Duplicate patch instead of a conflictor, but
their commutation behavior is exactly the same as that of conflictors, it is
just not counted as a conflict. So with darcs2 we have the same situation.
