[darcs-users] How to extend a patch theory to fully commute

James Cook jcook at cs.berkeley.edu
Tue Sep 8 19:47:54 UTC 2020


> >> In your case, for two adjacent /sequences/ A;B, and equivalences A~A',
> >> B~B', we need to have that A;B commutes iff A';B' commutes. Now, suppose
> >> you have patches a;b;b^;c, where none of the adjacent pairs commute.
> >> You'd have to show that this implies that a;c commutes neither (taking
> >> e.g. A=[a] and B=[b;b^;c]). But you can't, since it is not true. A
> >> counter example consists of 3 hunks a, b, c, where a and b overlap, b
> >> and c overlap, but a and c do not overlap. More concretely, take the
> >> initial state as file f=[1,2,3] and
> >>
> >>   a=hunk f 1 [1] [1a]
> >>   b=hunk f 1 [1,2,3] [1b,2b,3b]
> >>   c=hunk f 3 [3] [3c]
> >
> > I'm still not sure I understand the problem. I agree that in your
> > example, it's possible to commute [a] with [c] but not [a] with
> > [b;b^;c]. But it is possible to "rearrange" a;b;b^;c into b;b^;c;a if
> > "rearrange" is defined broadly enough to allow the following three
> > steps: a;b;b^;c -> a;c -> c;a -> b;b^;c;a.
>
> Commutation means that we may have to re-arrange the /content/ of the
> patches we commute, such that they make sense in their new context. You
> abstracted that part away here. If we re-add it, the sequence becomes:
>
>   a;b;b^;c -> a;c -> c';a' -> b';b'^;c';a'
>
> But what is the new b'? It should be clear that, in general, it cannot
> be the same as b: if b depends on a (which is what we assumed), then
> that means that b makes no sense without having a before it.
>
> Take the above three hunk patches and tell me how b' should be defined
> such that the resulting sequence b';b'^;c';a' makes sense.

Oops, I didn't pay enough attention to your concrete example.

Did you mean b = hunk f 1 [1a,2,3] [1b,2b,3b]? (I'm guessing hunk f n
[u,v,w] [x,y,z] means lines n..n+2 of file f start out as [u,v,w] and
end up as [x,y,z]; is that right?)

Then yes, I guess the order b;b^;c;a is not possible.

I really want this to work, though, so now I wonder what happens if we
just accept the situation: even though c can be rearranged to b;b^;c,
and a;c can be rearranged to c;a, it turns out we can't combine the
two to rearrange a;c to b;b^;c;a.

I guess it's kind of ugly that changing the context can change what
rearrangements are possible: in this case, the rearrangement c ->
b;b^;c may be possible or not depending on whether a patch named "a"
has been applied. This is cause to be suspicious, but is there an
obvious reason it's unworkable?

James


More information about the darcs-users mailing list