This is just the Nest, not Pijul. I'm responsible for that, and sorry about it. I said I'd fix it soon, at the moment I'm working on an app to fix (a small part of) France's electricity crisis. It's mostly done, but it took me a while to write something that would be able to scale to loads of users before the winter.
I'm just following Rustacean traditions of fixing things from the root.
When you have to write a web browser, you do have to fix C++ before you can actually start. I'm digging a bit deeper by avoiding blackouts so my French servers keep running (the Nest has two other locations), then I'll fix the server code.
I'm interested in Pijul and the theory I've read about the patches model makes sense but I'm still looking for an answer to my standard question on Pijul:
"What real world situation does git barf at that Pijul would handle better". I'm sure there is one, but I have yet to see it.
All of the following is described in the Pijul manual:
- Cherry-picking in Pijul actually works.
- Conflicts: you don't need rerere, conflicts don't come back once you've solved them. Conflicts are the most confusing situations, this is where you need a good tool the most.
- So-called "bad merges", where a merge or a rebase goes completely wrong and shuffles your lines around. Git users rarely only call the lack of associativity a "bad merge" and don't look further, but using 3-way merge is the wrong way to merge things, because there isn't enough information to merge correctly in all cases.
- Depending on your pace of work, you might find yourself working on different things at the same time. Pijul allows you to do that without worrying too much about how you'll eventually organise your work. If I worked with Git for example, I'd spend a lot of time organising my branches, they'd never be right, and I'd spend a lot of times rebasing afterwards. Pijul frees me from that work.
- Large files, but Git doesn't treat them well for historical reasons, not for reasons inherent to its design (unlike the other points).
Pijul handles all merges predictably, by design, because it doesn't actually merge anything, it just applies changes to a CRDT, and CRDTs work.
CRDTs aren't common in real-world distributed applications because they are hard to design. But when the problem is important enough (like in this case) I think the approach is worth it.
One way for Git to do what you said would be to import the repos in Pijul, commit by commit since the last common ancestor, instead of doing a 3-way merge. Technically feasible, but the performance would be terrible.
So what made me finally quit, i Was working on two machines and has a lot of conflicts after diversion. At some point magit crashed (my fault). Trying to merge them was very frustrating.
pijul doesn't scale to big repositories (tried to convert the oldest commits from hg.mozilla.org/mozilla-central, it didn't like it, and that was a tiny fraction of the repo...)
