Hadn’t heard of this before. The blog post linked from the home page on Pijul’s merging algorithm is super fascinating: https://jneem.github.io/merging/
I found it to be the only convincing argument for the use of category theory in programming I’ve seen. I’m not sure one could arrive at or explain the design of their data structures and algorithms without explaining that they’re what make pushouts work. It really feels like a Grothendieck-style compass-bearing use of category theory to discover the structures one should be looking at.
Availability on sourcehut would be a real-world test, I think.
Would be happy to see this on sourcehut. I think the main blockers for Pijul are:
If anyone working on Pijul is interested in building a Pijul backend for sourcehut, feel free to reach out! Email ~firstname.lastname@example.org or join us on IRC at #sr.ht @ irc.freenode.net.
Has anyone here used it in earnest? I had reason to be upset with git again last week and was considering making the jump back to mercurial, but if this is as close to ready as it sounds, I might give pijul a shot.
I’m one of the authors of Pijul. It’s obviously not as “ready” as Git, and you can probably expect some hiccups, but they should be quite minimal, and even more minimal if your repositories are stored on nest.pijul.com: the current repository format is probably not going to change much, but I did convert repositories on the Nest between versions in the past, every time a change happened.
The disk space usage of Pijul is still relatively high compared to Git, and (in part because of that), super large files are not very well supported yet. But this should be mitigated in the next release.
I believe people have found the SSH interface to be quite stable: we were hearing lots of complaints a year ago, they’ve mostly stopped now (maybe these users have also stopped using Pijul, I don’t know ;-) ). The HTTP interface is still relatively slow, and breaks sometimes (I believe this is because nest.pijul.com runs on one small machine).
Another painpoint is the tooling: I’d love to be able to use Pijul from within Emacs, and also have a fetchPijul command in NixOS, but no one has written them yet, and these things are out of my focus at the moment (I try to focus on Pijul’s development, among other things).
Edit: also, yes, we’ve been using it ourselves for two years now. It was much harder in the beginning than it is now. Also, bootstrapping is not always completely obvious: in the last few weeks, I’ve authored patches named “This patch contains a fix that allowed me to record it”. The latest simplifications in the algorithms gave me reasons to believe that this is mostly behind us now.
thank you for writing about your project. Looking around your website, I only could get a rough conceptional idea how pijul would be advantageous in comparison to say, git or other versioning systems. I read a bit through your category theory based explanations of your merging algorithm - unfortunately, for me at this point, a real world example might help here, e.g. a python program or something similar. Would you perhaos have such an example at hand?
This is a good series of blog posts that explain why patches are fundamentally different from commits:
The fundamental idea is that each line has its own identity, and a patch is the addition and removal of identified lines. This means that to get to your repository to a certain state, you look at the patches that get you there, and you apply them, where that means reconstructing the file out of uniquely identified lines. This means that in some cases you can reorder your patches with no problem. It also means that you have better tools for resolving merge conflicts.
In snapshot-based systems like git and Mercurial, every reordering of commits requires a merge. Most of them are usually automated, but when they’re not, you’re dropped into a dreaded merge conflict and place the user into a situation they would really like to not be in.
Patches don’t guarantee that there won’t be any merge conflicts, but patches have more information to help you resolve conflicts when they happen. Since each line has its own identity, Pijul can make merge conflicts less likely to happen and easier to resolve when they do.
Here is a concrete example of a Git merge doing the wrong thing on a C program: https://tahoe-lafs.org/~zooko/badmerge/concrete-good-semantics.html
Quick question, I have many repos that use darcs. Is Pijul stable enough to replace darcs yet? Is there any reason for me to stick with darcs for now?
It is not stable enough to replace darcs completely, in the sense that it is very unlikely that darcs will ever change its repository format, whereas we might still change that a little bit in Pijul. The patch format is almost certainly stable, which means that conversion will be just a matter of re-cloning existing Pijul repositories, but there will still be a conversion step.
For full disclosure, I still use darcs for some parts of the development of Pijul, such as the Nest, to avoid bootstrapping issues whenever possible.
Still, it’s exciting to see that darcs’s ideas evolved and matured to make Pijul. Is there a darcs->pijul import? I guess if there is a git->pijul import than I can do darcs -> git -> pijul.
A side note, I tried compiling pijul. I have rust 1.32 and I’m stuck at downloading crates! Cargo actually segfaults, so I’m kind of stuck until I update rust. But it makes me sad to see segfaults in rust since, like, it tries really hard to avoid them as a language!
Pijul is indeed tested on the latest stable Rust. I’ve seen segfaults in Cargo and Rustc before, they were due to a linking problem in NixOS. Can you try to find out which crate causes a segfault?
I just tried again (after many tries) and now it just works. I guess I had the right bits in memory this time. It’s built now, thanks.