[darcs-users] Make darcs force-commute patches from CLI, to learn about darcs?
jcook at cs.berkeley.edu
Fri Jun 26 03:03:55 UTC 2020
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 . 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
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
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
, 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
(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
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?
 "Understanding darcs" on Wikibooks, "A formalization of Darcs
patch theory using inverse semigroups", and some of Camp's
More information about the darcs-users