What they seem to be describing is basically a CRDT known as WOOT[0] from what I can tell. The category theory paper they refer goes a bit over my head, so maybe there’s more to it than rediscovering WOOT.
Pijul is indeed vastly different and significantly more complex than WOOT, in that it handles conflicts (whereas WOOT doesn't). Conflicts are fundamental for asynchronous systems, but don't matter that much for synchronous (or almost synchronous, like WOOT) ones, since users usually notice them immediately as they type.
All CRDTs are fundamentally asychronous, theres no requirement for them to be used in a Google Docs live editing type of setup, so as far as conflict resolution goes I still don’t see any major difference between this conflict resolution strategy and WOOT (aside from character vs line-level units).
It also suffers from the same problem as WOOT that while it’s mathematically (merge) conflict free, you still need to resolve semantic (merge) conflicts before the result is sensible, like in the final example.
I didn't say otherwise. However, Google Docs and WOOT are meant to be used "almost synchronously" (which is why I wrote "almost synchronous" in my answer), in the sense that conflicts are presented to the user almost instantly.
By the way, in the paper you mentioned, the words "synchronous" and "real-time" are used to describe WOOT.
The idea of composing patches really reminds me of of a series of blogposts I read about how Google Wave worked, I think it was called Operational Transformations it has seemingly disappeared from the internet but I remember it being a mind-blowing read at the time.
Sorry for being ignorant, but isn't git patch-based? I always thought of git commits as patches. You can directly convert one into a patch and vice-versa.
Not exactly, git creates a snapshot of the working tree for every commit.
The clever bit is that the object store stores files by their hashes, so if two snapshots have identical files they won't be stored twice.
As others mentioned, while git shows you diffs, internally it's actually snapshots of the entire repo, with each snapshot listing 0 (initial commit) 1 (normal commit) or more dependencies (merges).
While it works decently, the big problem with this model is its notion of dependency is too course. For example, let's say I'm working on two completely separate things, A and B, and I happen to work on A one day, and on B another, for three days, so I end up doing work A1, B1, A2, B2, A3, B3. In git, I'd end up with the following dependency graph:
A3 -> B3 -> A2 -> B2 -> A1 -> B1
The problem is these are not the real dependencies! If I decide, "oh, you know what, let's drop B and try C," there's no easy way to do that.
In a patch based system, instead, the actual dependencies of every commit are calculated. So in that system, I end up with the following graph:
B3 -> B2 -> B1
A3 -> A2 -> A1
And then it's very easy to say things like "drop B".
(A special case of this that's a big pain-point in git is cherry-picking bug fixes between branches. When you do that in git, git has no actual notion of what happened; it's not obvious looking at any given commit if it's been cherry-picked somewhere else, and you frequently get merge errors later on. If the thing you want to cherry-pick is actually multiple commits, you have to carefully go through and try to cherry-pick them in the right order. It's a huge pain point that a patch-based VCS promises to solve.)
To understand the basic idea, this series of blog posts is excellent:
https://jneem.github.io/merging/
To me, it seems clear that a patch-based VCS is the future. Whether or not it will be pijul that brings us this future, I don't know...