How does it compare to Darcs?
https://hackage.haskell.org/package/darcs
Edit: Better link is http://darcs.net/, darcs has been around for more than 10 years and is still actively maintained.
https://hackage.haskell.org/package/darcs
Edit: Better link is http://darcs.net/, darcs has been around for more than 10 years and is still actively maintained.
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.
For the sake of completeness, I don't know the full story for the complexity of Darcs "in most cases", but I believe it to be linear in the size of history in the normal case (as it needs to try and commute all the patches with your new patch).
IME, darcs has never lost a repo of mine and Pijul has. So I'm not clamoring to use pijul instead - I don't use darcs in a way that runs into the pathological cases anyway.
Not sure whether there's any actual advantage at all.
Look at nest.pijul.com for example, or the satellite projects such as Thrussh (https://cargo.io/crates/thrussh), which aim at making the UX as smooth as possible.
Would consider for a new project, somewhere else, though. I really miss my perfect understanding of SVN when I get lost in some Git madness - it's obviously way more powerful and faster but sometimes I get into merge scenarios where I have to go edit files just to restore whatever I just did on another branch or what-have-you. Editors papering over this with extensions to "resolve using theirs" etc. help but seem like an ugly fix.
I am interested in https://www.unisonweb.org/ which I saw here recently as storing its code in a fundamentally different way that helps make ugly merge conflicts a thing of the past by making the on-disk format (and therefore the revision control system) aware of some aspects of the AST. I'd love to see this go further and have a "no conflict" merge take place as long as two edits to a single file touched different functions and the merged version passes some tests or whatever.
Not really. If they're not heavily relying on the "darcs replace" feature, it's just the same interface. The dependencies between patches are computed differently.
Be careful though, Pijul is still 0.12, the patch format will change.
> I'd love to see this go further and have a "no conflict" merge take place
This seems possible in a future Pijul. Right now we're just starting to get text files right! Let's see in a few years.
I've yet to find anything comparable for repository hosting. I use it for projects where some of github's features are frivolous, but it would be a bit goofy adopting it at a big company.
I don't know what GHE is, but making me interact with github or bitbucket isn't a good way to encourage me to contribute to projects, especially fixing incidental bugs in things I use. Each to their own, after some decades' experience of effective distributed development.
GHE is Github Enterprise. Most software development teams use that or Bitbucket or Gitlab, because there's a ton of value in the visual interface, the approach to code reviews, approvals, etc. that is hard to recreate in any other form.
You still push Git patches to it the same way as you would to any other Git repo.