Hacker News Reader

Comment by cutierust | Hacker News Reader

Just use pijul. Backend might be good but I'm tired of gits ui and am impressed with pijul so far (very unfurnished yet,)

View on HN

I would, but PIJUL IS BROKEN* and nobody has fixed it since it was reported. [1]

[1] https://discourse.pijul.org/t/signup-on-pijul-nest-gives-for...

* forgive the caps, I know I have sinned but I do wanna be able to use this VCS.

That's nest not pijul.

People can’t develop on/learn Pijul if Nest is broken.

Ssh is enough to a central machine if multiple people are involved. But what stops you from local development?

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.

Thank you for the update, and the electricity crisis is (probably... :P) more important. No biggie.

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.

There are some types of merges that pijul would handle better, but technically, git could too, if it spent more time on them.

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.

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 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...)

That doesn't match our experience, have you reported this?

Reply on news.ycombinator.com