Pijul: a distributed version control system, written in Rust (2019)

Previous discussions:

https://news.ycombinator.com/item?id=18654958

https://news.ycombinator.com/item?id=18235798

https://news.ycombinator.com/item?id=13643025

https://news.ycombinator.com/item?id=10470281

From https://pijul.org/manual/why_pijul.html#patch-commutation:

> In Git, importing just a few commits from another branch is called "cherry-picking", and involves changing the identity (the hash) of those commits. This usually works the first time. However, when done again, as the maintainer of a stable branch probably wants to do, this often causes counter-intuitive conflicts.

If you're doing this in git to apply a fix to a master branch and multiple release branches, you're doing it wrong. You should be basing the patches off the merge-base of master and the oldest release branch you wish to land the change into.

If you work this way, you can merge the patch cleanly into all target branches, and this new patch becomes the new merge-base. So you can actually continue to apply new patches without any conflicts.

But you don't want your VCS to dictate your project management.

Maybe you want to apply the patch to the main development branch, let people try it there for a while, and then decide which maintained release branches should get the patch.

> If you're doing this [..], you're doing it wrong. [..]

This is not 100% true (see my answer to the second part below), but the point of Pijul is that you don't need to "do things right" to avoid the potential problems of your version control system. In the end, a version control system is just a tool, not a way of life or a work methodology.

Sure, there are example projects where the Git way is the best, but they are quite rare (one example is Software Heritage [1]).

> If you work this way, you can merge the patch cleanly into all target branches, and this new patch becomes the new merge-base. So you can actually continue to apply new patches without any conflicts.

This is not actually true, and is the whole point of Pijul. In Git, your suggestion works only as long as (1) there is never any conflict, else you need "git rerere", and (2) 3-way merge never runs into a non-associative merge [2].

[1] https://www.softwareheritage.org/ [2] https://tahoe-lafs.org/~zooko/badmerge/simple.html

From a complexity theory perspective, the Darcs patch application algorithm runs in time O(2^n) in the worst case, where n is the number of patches since the beginning of the repository. That exponential merge happens in practice.

In Pijul, it is always O(log n + c), where c is the size of the largest conflict between the current repository and the patch you're trying to apply.

So, it is a double-exponential improvement in practical uses, even though you could totally make c = n for the sake of the argument.

The tradeoff is that Pijul doesn't handle the very cool (but rarely usable in practice) "darcs replace".

From an implementation perspective, Pijul is in Rust, relies on less external stuff than Darcs (for example no need for Putty on Windows), is available as a library.

edit: also, Pijul has branches, too, and Darcs doesn't. But branches are far from being as useful as in Git, and in fact most Git workflows use short-lived branches, which are essentially just patches in both Pijul and Darcs.