Joe Neeman writes about version control theory, patch-based merging, Pijul, and Rust, including porting audio code from C.
HN commenters point to his merging and patches series as a clear explanation of how patch-based version control like Pijul works.
From my limited knowledge (mostly based on jneems article series[1]), I think Pijul is more powerful, but for the same reason also considerably more difficult to understand than Git.
In particular, Pijul supports (and depends on) working with repository states that are, in Git terms, not fully resolved. In addition, those states are potentially very difficult to even represent as flat files (see e.g. [2]). Git is simpler in that it mandates that each commit represents a fully valid filesystem state.
That said, I still think Pijul might have a place, if it turns out that it supports superior workflows that aren't possible in Git. But the "VCS elitism" would probably become worse than it is today.
[1]: https://jneem.github.io/merging/
[2]: https://jneem.github.io/cycles/
From the title, I was rather expecting an argument along the lines of "Git is not revision control of code, but of snapshots of a filesystem"; I opened the link expecting to see an introduction to a patch-based system like Darcs or Pijul.
Pijul's theory, in particular, is extremely intuitive (if your intuition extends to "cocompletion of the category of files and patches", anyway) and it truly is born for the task of versioning text (and hence code). Git, by contrast, versions anything, with the result that very weird and counterintuitive things can happen when you merge branches. I recommend https://jneem.github.io/merging/ for a glimpse of what a distributed version control system could have been.
I am a mathematician and generally bearish on category theory in programming. The best argument for it I've seen so far is that it can inform the design of your system to give it desirable properties, like how the DVCS Pijul [1] bases its data structures on patches and its merge operation on categorical pushouts [2] -- also explained at length in a series of blog posts [3]. I found the whole idea and reasoning behing the merge system very convincing, and am not sure it could have been arrived at or explained as clearly without category theory guiding the way.
[1] https://pijul.org/
[2] https://arxiv.org/abs/1311.3903
[3] https://jneem.github.io/merging/
I found this [0] to be a very readable presentation of the theory behind Pijul. Key point is that by representing state as an "DAG of lines" instead of as an "ordered list of lines" (i.e. a file), you are always able to do perfect merges.
You then need a "flattening" step to get to a normal file, but that is handled same as any other patch.
All in all, I am a tempted to give this a try -- even though the mental model will require some mental rewiring.
[0]: https://jneem.github.io/merging/
Am I reading this right that this is the algorithmic fix, but it still needs a concrete implementation - and then the main server should be back down to "vertically scalable"?
Without going and reading the doc(yet); does this relate to:?
https://jneem.github.io/merging/
It would seem that a simpler, deterministic merge algo would be possible to parallelize - but I'm not sure if it's easy to match matrix idea of merges with what's discussed in that post/paper?
Git has a really simple view of changes. That is, none. It just saves blobs. It doesn't really know what you commit. For example it doesn't know if commits are independent of each other.
Darcs was also from the 2000s but unfortunately not fast enough to compete with git.
If you want to see what a post-git VCS might look like, read this introduction to pijul, a VCS that is based on patches and not on blobs like git:
https://jneem.github.io/merging/