I don't buy (as sold) the argument that we need associative and commutative merges, and I believe that this constraint when applied by the software makes resolv

I don't buy (as sold) the argument that we need associative and commutative merges, and I believe that this constraint when applied by the software makes resolving merge requirements harder on the user, rather than easier. It's punting the slightly more solved part of the problem back on the user, when it's one of the least favorite parts of the problem for the user. The solution that he writes up is basically "git merge" and part of the reason that we have such a bad time with git is that the industry largely standardized on "git rebase", which destroys many of the properties listed: changes are partially ordered: if you merge, this is true, if you rebase, this is not, your change is strictly reodered atop the merge base, and you dear user are responsible for the hell of fixing the constant conflict this produces, even if an alternative merge order would implicitly fix this. when pijul says "partial ordering" here, it means (in slightly abstract and minutely different terms) it's doing what git merge does, because it's better. As it happens one of the various reasons rebase became popular was that `git log` order shifts around for efficiency and correctness reasons, when people mostly want the output of `git log --topo-order` by default, which for the common case of "merge right onto left" presents "right first, then left" in linearized history, unless there's a content defined order. Pijul dodges the presentation problem by just not presenting this information at all. Git's mistake was in many ways not hiding enough from users - but it came from kernel engineers, who don't want things being hidden. No git rerere: rerere is a hack to try to make rebase pretend that it doesn't drop usable merge information on the floor, if you stop imposing rebase on yourself you don't need the rerere hack. Partial clones & large files: these are storage structure optimizations, and yes, a problem for git, though for example git lfs approach is similar in solution to the described pijul solution: "we only need a description of operations" - that's how you would describe lfs changes. As it happens, that's also how you would describe subproject updates, and yes, sure subproject UX isn't great, but now we're back to a UX problem, not a storage problem. Working with large graphs: cache snapshots and index deltas, um, yeah. You don't have to squint very hard to draw equivalence here either. I'm not apologizing for git, but there's a lot of "here's some non-ascii literals on a slide, it's science" presented, but not actually a very substantial shift in trade-offs when applied in practice. There are some pathologies improved, and some worsened, and there are some more onus put on the user for some cases, and some removed for other cases. It's a very different (at the minute level) structure, sure, but I've not been sold that it makes a set of trade-offs that substantially change the game, it's just the other side of the field, not all that dissimilar from choosing between two different database engines. An example of it not being that different in practice: can you conflict with yourself in pijul? Absolutely, and you end up with the pijul version of merge commits, e.g. https://nest.pijul.com/pijul/thrussh/changes/7S7FHFDVSSRB4DCBZINHNWM3QJS6KYAR2L2HADDBDN4IHKN6KGLAC https://nest.pijul.com/pijul/thrussh/changes/7S7FHFDVSSRB4DC..., more than that you can conflict with yourself multiple times (which is basically the rerere problem but actually distributed, which was somewhat erroneously claimed to be eradicated). It hasn't substantially moved the needle on merging history quality _in practice_. The manual is very incomplete on this, i.e. https://pijul.org/manual/conflicts.html https://pijul.org/manual/conflicts.html and there are some nascent but very slow tools to unhide the totality of conflicts in a repo https://nest.pijul.com/laumann/pijul-conflicts https://nest.pijul.com/laumann/pijul-conflicts which would bring the rerereal problem (couldn't resist, sorry) into the light. What's the largest team concurrently working on one project full time using pijul today? I ask because small numbers of users don't create many interesting conflicts often, and don't provide a good insight for the properties of a VCS at scale/in practice. You can use CVS with zero problems when you're on your own. There's an embedded theory which is that you can do very lazy conflict resolution requirement and that it'll pay off. I'd like to see that theory tested at scale.