Thanks, Ben! Responses inline. If you have the time, I'd be curious to hear about why my expectations didn't match what darcs actually did.
> > What I'd like to do is create a repository R1 with patches A and B, > > and then look at the patches that result if A and B get > > force-commuted. > > > > E.g. if I could pull just patch B and not A to a new repository, I > > think that would do the trick, but of course darcs pull won't let me > > do that because B depends on A. > > The main question here is: What do you expect the result of such a > force-commute would be? > > Let us take a very simple example: > > A = addfile ./foo > B = hunk ./foo 1 [] ["some text"] > > where the hunk notation is simplified but hopefully understandable (the > hunk here removes no lines and adds the line "some text"). > > Suppose you had a 'darcs force-commute' command, and you force-commuted > A;B to B';A'. What would you expect the B' then A' to be? I've been reading about patch theory [0]. I *thought* what's supposed to happen is this: * The effect of B' is the same as the effect of A. (i.e. create the file) * The effect of A' is the same as the effect of B. (i.e. add "some text") * Therefore, B'A' does the same thing as AB. * B' and A' include some information about the conflict, in addition to their effects described above. (They are "conflictor" patches.) * If I commute B' and A' again, I get back AB, since <-> is a symmetric relation. However, that doesn't seem to be what happened (see below). Even if that were correct, it still doesn't leave me with a complete picture of what darcs actually does, so I wanted to experiment. > > Question 1: Is there a simple way to make darcs do this? > > Not exactly simple, but it is possible: > > darcs clone . ../saved > darcs rebase suspend # select B and A > darcs rebase obliterate # select A > darcs rebase unsuspend # select B > darcs pull ../saved # select A > > You should expect to get conflicts first when you unsuspend B (after > obliterating A) and then also when you re-pull A from the clone. You > will probably want to amend the conflict resolution into the conflicted > patch. Thanks, that seems to have worked. (I only got the first conflict, not the second.) But now I'm confused. Based on, for example, the "Forced commutation" section of https://en.wikibooks.org/wiki/Understanding_Darcs/Patch_theory_and_conflicts , I expected B' to add the file "foo", and A' to add "some text" (so, B' has the effect of A and A' has the effect of B). Instead of that, I get this: (a) If I follow your advice and amend the conflict resolution into B' before pulling, then (the amended) B' has the effect of AB, and A' has no effect. (b) If I run "darcs revert" instead of amending the conflict resolution into B', then B' has the effect of A and A' still has no effect. Confusingly, darcs offers to pull B from ../saved --- I thought darcs should consider it to already be present (as B'). I also noticed that if I run the swap a second time, I don't exactly get A and B back. (In the (a) case, I get patches with the same effects, but the new B starts with "duplicate"). I thought commutation was always supposed to be symmetric. Does that not apply when conflictors are involved? > Cheers > Ben Thanks, James [0] "Understanding darcs" on Wikibooks, "A formalization of Darcs patch theory using inverse semigroups", and some of Camp's "theory.pdf" _______________________________________________ darcs-users mailing list darcs-users@osuosl.org https://lists.osuosl.org/mailman/listinfo/darcs-users