### Re: [darcs-users] RFC: Hiijacking Patches

On Fri, 25 Sep 2020 at 10:48, Ben Franksen wrote: > Hi Everyone > > I am thinking about changing the behavior and/or available options for > hijacking patches. > > Context: When working from home I have two identities in my > ~/.darcs/author file: one with my work email address and one with my >

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

> So this can succeed only if c does not conflict with either of its > sibling cancelled branches, that is, if c^ commutes with all sequences > ("paths") in the cancelled branches, that is, all elements of {d, e;f, > e;g, e;h;i}. We then get > > a--b'-c' > |\ >d' e'-f' >

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

> > 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?) > > Yes to both, sorry I messed up the

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

> >> 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

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

On Thu, 3 Sep 2020 at 14:24, Ben Franksen wrote: > > >>> If I wanted to implement it, I think it would just become this: > >>> > >>> * A repository consists of two things: > >>> * A sequence S of primitive patches with distinct names, starting at > >>> O, with no inverses (i.e. only positive

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

> One a minor note, your patch universe definition is not suitable for > extended patches as defined in Darcs: For these, the square commute law > (which you call rotation, perhaps a better name) does not hold. Though > to be fair, a while ago we have stopped treating them as invertible in > the

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

On Wed, 19 Aug 2020 at 11:52, Ben Franksen wrote: > Am 19.08.20 um 11:44 schrieb Ben Franksen: > > The fact that your patches have no "content" is of of course a result of > > starting out with "enriched" contexts. As you note in 2.2 > > Interpretation, your contexts can *not* in general be

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

> I changed the definition of Context > Address to work better with my new "patch universe" definition, but I > think it amounts to the same thing. Thinking about it more, I'm not sure my new definition of Context Address is a good one, since I've been finding it hard to associate a primitive

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

> >> A good way to see if your definition holds up is to see whether you can > >> prove your > >> > >> Conjecture 1: Every context address points to at most one context. > > > > Sure, that's a nice goal. > > > > I think I will start a latex file, try to define what a patch theory > > is and what

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

Question: is there a good place to read about how "darcs pull" works? You mentioned hashed inventories in an earlier email; I guess I could look at the darcs source keeping that in mind. (I've been thinking about reading some of the source code anyway). It's relevant to the last part of this

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

> > and whether it's okay to restrict S to be tree-like during the > > intermediate steps. It is probably simpler to just drop the cycle > > version and think only of trees, but I want to make sure I understand > > how the primitive patch theory's commuting rules turn into tree > >

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

On Mon, 6 Jul 2020 at 10:29, Ben Franksen wrote: > Am 05.07.20 um 20:36 schrieb Ben Franksen: > > Am 04.07.20 um 23:59 schrieb James Cook: > >>> I think that whenever a sequence of patches starts and ends at a > >>> primitive context (e.g. this is true of an uncon

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

> > I don't know how darcs figures out what patches need to be pulled, > > especially if R1 is lazy. > > Don't let yourself be confused by lazy repos. > > Conceptually, darcs reads the complete remote repo, figures out the > common patches, commutes all uncommon patches in both repos to the end, >

### [darcs-users] Make darcs force-commute patches from CLI, to learn about darcs?

Hi darcs-users, I'm trying to learn more about how darcs force commutes work. 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

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

> I think that whenever a sequence of patches starts and ends at a > primitive context (e.g. this is true of an unconflicted repository) > you can re-order the patches so that they are all primitive. I should add: this probably requires allowing new permutations that weren't in the primitive

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

On Sat, 4 Jul 2020 at 16:05, Ben Franksen wrote: > Hi James > > It was an interesting journey through the sea of patches! > > I think your construction is sound. I have somewhat skimmed over the > more complicated proofs, but I trust they contain no grave mistakes, > given that your exposition is

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

On Sat, 4 Jul 2020 at 09:59, Ben Franksen wrote: > Am 04.07.20 um 00:10 schrieb James Cook: > >>> I'd say this is a feature, not a bug. If you mark the conflict between A > >>> and B as resolved, *without* recording a new patch, then this means you > >>

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

> > I'd say this is a feature, not a bug. If you mark the conflict between A > > and B as resolved, *without* recording a new patch, then this means you > > are satisfied with the resolution that reverts both changes. There is no > > reason why pulling C should conflict now. If, on the other hand,

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

> > But yes, I realized after writing it that I never covered inverting > > extended patches. > > > > Thinking about it more, I think I've found some problems. Let's say s > > is the starting context of A and B, and A ends with a and B ends with > > B. Here are three problems: > > > > (a) I'm not

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

On Thu, 2 Jul 2020 at 18:40, Ben Franksen wrote:> The final chapter about the effect of extended patches and how to > resolve the conflicts they represent could use a bit of elaboration. For > instance, though you refer to the process, you haven't explained how > (extended) patches are merged. I

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

On Thu, 2 Jul 2020 at 09:42, Ben Franksen wrote: > Am 01.07.20 um 05:09 schrieb James Cook: > > Definition: We associate a primitive context to every context address > > (and in particular to every extended context) (a, b, (Qi), X, Y) using > > the following recursive algori

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

On Thu, 2 Jul 2020 at 09:12, Ben Franksen wrote: > Am 01.07.20 um 05:09 schrieb James Cook: > > The overall procedure is this: > > > > 1. Merge the individual patches to be permuted into a patch sequence > > address (a, b, (Qi), (nj), X, Y). (You could merge a p

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

On Thu, 2 Jul 2020 at 08:57, Ben Franksen wrote: > > Definition: Let A=(a, b, (Qi), (nj), X, Y) be an patch sequence address > > of length n (i.e. (nj) has n names in it). The /separation/ of A is a > > sequence of n extended patches. Patch j in the sequence is the minimal > > form of (a, b,

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

On Thu, 2 Jul 2020 at 08:32, Ben Franksen wrote: > > Definition: A /patch sequence address/ is a tuple > > (a, b, (Qi), (nj), X, Y), where a and b are (primitive) contexts, (Qi) > > is a sequence of (primitive) patches going from a to b, nj is a sequence > > of unique names of patches in (Qi),

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

On Thu, 2 Jul 2020 at 07:53, Ben Franksen wrote: > Am 02.07.20 um 00:37 schrieb James Cook: > >> The construction works by inductively taking any pair of incommutable > >> patches (in sequence, i.e. with a common middle state) and then > >> "formally" c

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

> Thanks for writing this down. I think you should add this example to > your text as it is a good illustration. Good idea; done at https://hub.darcs.net/falsifian/misc-pub/patch/5571a2e0c22659114fd5a919e06be844819afccc . James ___ darcs-users mailing

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

> The construction works by inductively taking any pair of incommutable > patches (in sequence, i.e. with a common middle state) and then > "formally" commuting it. The new node is represented as that pair of > patches. Is that, essentially, the idea? Sorry, I should add one note here: I'm not

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

On Wed, 1 Jul 2020 at 21:14, Ben Franksen wrote: > Am 01.07.20 um 18:45 schrieb James Cook: > >> Just to check I understood the idea (up to this point): roughly > >> speaking, you represent "unrepresentable" states by formally commuting > >> patches. >

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

> BTW, you don't say it explicitly, but since in several places you refer > to names, I was assuming that in your theory prim patches are always named. Yes, I'm assuming every prim patch has a unique name. Part of the tuple encoding an extended patch is the name of a prim patch. That could be

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

> Just to check I understood the idea (up to this point): roughly > speaking, you represent "unrepresentable" states by formally commuting > patches. > > That is, if we regard the primitive states as vertices and primitive > (named) patches as edges in a graph, then you extend the graph with new >

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

> A well-known and quite natural way to identify the equivalence class of > all patches that a given patch P can be commuted to, is to use the so > called "minimal context". A minimal context C(P) for some patch P is a > sequence of patches starting at the empty state and preceding P, and > that

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

On Wed, 1 Jul 2020 at 10:12, Ben Franksen wrote: > I haven't fully digested everything you wrote but I guess a remark may > be in order, lest you waste time on something that cannot be implemented > efficiently. I am not claiming this is equivalent to what you aim at, > but I think it is at least

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

On Wed, 1 Jul 2020 at 10:21, Ben Franksen wrote: > Am 01.07.20 um 05:09 schrieb James Cook: > > The context address /points to/ a context c if there exists a > > permutation of (Qi) such that all the patches with names in X come > > before patches with names in Y, and c

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

On Wed, 1 Jul 2020 at 09:44, Ben Franksen wrote: > Am 01.07.20 um 05:09 schrieb James Cook: > > Example: Suppose a is the starting context (empty repository), Q1 > > creates the file "foo" starting from a, Q2 creates the file "bar" > > starting from the

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

== Prologue == This is a story about how to extend a patch theory into one where any sequence of patches can be permuted into any other order. In particular, this means every merge is a clean merge in the new theory. One small catch: after a conflict, it's not possible to continue applying

### Re: [darcs-users] Make darcs force-commute patches from CLI, to learn about darcs?

> It had never occurred to me to think of that as a possible solution. > Sometimes it helps to get input from someone who is not as deeply > involved and who can come up with fresh ideas. Many thanks for sharing them! Glad it turns out to be at least plausible. Thanks for taking the time to

### Re: [darcs-users] Make darcs force-commute patches from CLI, to learn about darcs?

> Another problem is that even supposing commutation does not change prim > patches, in darcs you still have conflictors. And conflictors > /definitely/ have to change representation when we commute them: the > merge-commute law obviously requires that. Could the conflictors be re-computed? In

### Re: [darcs-users] Make darcs force-commute patches from CLI, to learn about darcs?

> There is also more than just hunks. What about file renames? A file > rename commutes with a hunk that changes the file, and in darcs this > changes the hunk patch to refer to the renamed file. You need to change > the internal representation to refer to files using UUIDs to get around > that.

### Re: [darcs-users] Make darcs force-commute patches from CLI, to learn about darcs?

> This in turn led me to the more general question of how to detect > inconsistencies when exchanging patches between repos. The problem here > is that darcs currently relies on global uniqueness properties that are > quite easy to invalidate (e.g. by manually editing patches, and as > hinted

### Re: [darcs-users] Make darcs force-commute patches from CLI, to learn about darcs?

> Converting existing repos to darcs-3 is unfortunately one of the things > we havent't done yet. I have implemented a number of conversion schemes > but they all fail in some situations. There are two hard problems to > solve here: > > (1) What to do about so called "Duplicates" in the darcs-2

### Re: [darcs-users] Make darcs force-commute patches from CLI, to learn about darcs?

> That said, you should be advised that both patch theory implementations > ("formats") currently in use, namely darcs-1 and darcs-2, have bugs. In > practice that means you may not be able to do such a separation for > complicated conflict scenarios, though I think if it succeeds then the >

### Re: [darcs-users] Make darcs force-commute patches from CLI, to learn about darcs?

> > 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

### Re: [darcs-users] Make darcs force-commute patches from CLI, to learn about darcs?

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. > > >

### Re: [darcs-users] Make darcs force-commute patches from CLI, to learn about darcs?

(re-sending 3 days later; sorry if this arrives twice) Hi darcs-users, I'm trying to learn more about how darcs force commutes work. 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