> >> 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 _______________________________________________ darcs-users mailing list darcs-users@osuosl.org https://lists.osuosl.org/mailman/listinfo/darcs-users