[darcs-devel] commuteNoConflict/cleanMerge etc

Ganesh Sittampalam ganesh at earth.li
Fri Sep 27 23:18:15 UTC 2019


> I would remove the class if it weren't for combineConflicts which uses
> commuteNoConflicts. While I am pretty sure it could be replaced with a
> plain commute, I am hesitating to make that change.

I'm sure you've thought this through/understand it better than me, but I
spent a while thinking about it so I might as well write it down.

My attempt to think this through:

If it made any difference, then with commute we would report more sets
of conflicts than with commuteNoConflicts, as more patches would make it
through 'passedby'. The cases where commute will succeed but
commuteNoConflicts fail are where we are undoing a conflicted merge. So
if we have a two-way conflict between a and b, and b' is the
merged/conflicted version of b, then our repo will have a;b'. Now a can
commute past b', so we'll end up reporting the same conflict twice.

The practical approach:

I tried running the tests with the change (with -t conflict). Only two
things failed: Darcs1 unit test conflict-chain-resolution, and Darcs2 Q
test "resolutions don't conflict". So it can't possibly be as bad as
reporting every single conflict twice, but it doesn't work trivially.

> On the practical side, I think that commuteNoConflicts should not be
> used, except for the legacy use in combineConflicts. This is why I have
> removed it from the RepoPatch constraint. For V3 we can simply regard it
> as part of the implementation of commute.

So...

commuteNoConflicts is (perhaps) needed for combineConflicts, which is
used for conflict markup for V1/V2.

commuteNoConflicts is also used by mergeNoConflicts which in turn is
used to define cleanMerge for V1/V2.

In V3 we define cleanMerge and commuteNoConflicts independently but we
can relate them by the law you gave. (Presumably with a sufficiently
advanced/magical program derivation tool we could actually derive one
from the other.) We then use them inside the definitions of commute/merge.

But why do we expose cleanMerge? I get that it makes defining V3
operations much clearer and allowed us to get rid of Rotcilfnoc, which
was previously only really needed as an intermediary between merge and
commuteNoConflicts.

But why do we bother implementing CleanMerge for V1/V2 or for things
above RepoPatch like Named/PatchInfoAnd?

> That doesn't answer your question about laws relating commuteNoConflicts
> with cleanMerge. I think there is a close relation, similar to the
> relation between the conflicted merge and commuteConflicting.

Could we factor out the non-cleanMerge cases of merge into a
mergeConflicting? And then can we relate mergeConflicting and
commuteConflicting like cleanMerge/commuteNoConflicts?

>   commuteNoConflicts p;q = Just q''';p'''
> <=>
>   cleanMerge p\/q''' == Just q/\p'''
> 
> This doesn't give us a way to implement one in terms of the other but it
> does allow us to check that they are consistent.
> 
> Does that make sense?

Yes, thanks.


More information about the darcs-devel mailing list