Without PijulHub getting a Series A, this will never take off!
I’m joking, but do have to wonder what the goals are here. If technical superiority is the goal, maybe that’s fine. If worldwide domination of DVCS ideology and usage is the target… well good luck! Git is going to be a tough competitor, but I guess if you play up the security of SHA1 enough…you might get some converts.
I know you’re kidding, but I’m very convinced that Git succeeded due to GitHub. But that had relatively little, in my opinion, with GitHub being good or easy or anything else. Instead, I am pretty sure that the actual reason GitHub succeeded was that it gave developers an auditable portfolio—via a blockchain, no less, before those were cool—and then the usual factors of tool momentum and social pressure caused GitHub to dominate industry as well. If a PijulHub could do a markedly better job at the portfolio aspect, I think that might have a pretty easy time unseating GitHub amongst hobby developers.
I’ll mostly leave what that actually means as an exercise to the reader, but I will note that the big thing Darcs-like systems do better than Git-like like systems is make long-lived personal tweaks (as opposed to hard forks) a lot easier to maintain and distribute. They are, after all, in a much truer sense than either Mercurial or Git, basically a way of distributing plain, vanilla patches, with dramatically more metadata than e.g. Quilt of yore. I thus think that a PijulHub that focused on lots of different neat customizations you could do to otherwise stock-standard open-source software might actually stand a great chance of unseating GitHub.
Anyway, that’s my two cents. Free business plan if you want it. I already tried this industry and don’t feel like a repeat.
GitHub also had an early, incredibly hard buy-in from an entire language community: Ruby. That helped quite a bit too. Network effects are tough.
Perhaps it’s too obvious to mention, but even before GitHub, git had a pretty important “launch customer”, so to speak, in the form of the Linux kernel. Not only is the Linux kernel a big project, but it’s also a project with a long reach into influential companies, since there are people in IBM, Red Hat, Intel, Google, etc. who routinely send code upstream, and who therefore all quickly started using git as soon as it became the official way to contribute.
maybe the goal is to build a system that works better for them? not everything is intended to take over the world.
That seems to be the case; it’s not a company that needs to turn a profit or anything. The specific motivations of the people behind Pijul are that they’re darcs users who were frustrated by some speed issues with darcs, plus a few other things about its patch theory, and thought they could do better.
I didn’t mean to imply that I felt that to be the case. But, typically, if you spend the time market a project, spend the time to make a marketing website (and not just generate documentation via Sphinx, Haddock, etc) you want it to be used. And, there’s nothing wrong with that!
Pijul will have to have some answer for extremely large repositories that can’t realistically be cloned in their entirety to have a real competive advantage over git. That will attract big corporations (and their money) who wish they could use git.
Pijul uses only patches, which are atomic components of team work. In Pijul, a branch is exactly a set of patches.
What’s the concrete advantage of using patch-theory? Or is it just fancier?
I’ve only worked on smallish darcs repositories (the DVCS that inspired Pijul), so haven’t exercised the patch-theory concept that heavily. But its patch-based approach means it works more like how I expected the idea of DVCSs to work when I first heard about it, especially regarding cherry-picking or merging. You can cherry-pick a patch from the middle of someone else’s repository that has a lot of other patches before and after, and apply it cleanly as long as those other patches aren’t logically dependencies or conflicts. With git’s snapshot-based approach, you not only have patches that really do logically depend on each other, but a lot of unnecessary dependencies due to the sequential ordering that make cherry-picking often not work without a lot of surgery.
For example, consider the case where one patch renames an identifier throughout the codebase, and another patch removes a function that uses that identifier. In many situations in git these patches conflict, because they both attempt to modify the same lines. But in many cases the patches in darcs can be reordered so they don’t, using the observation that the order here doesn’t matter logically. There are also a few types of semantic patches that make this especially useful in certain cases, e.g. renaming files is a separate type of patch, so if you cherry-pick someone’s patch that edits foo.c that you’ve since renamed to foobar.c, it applies fine (git does have a feature that attempts to identify renamed files heuristically to resolve merges, but it’s more hit-or-miss).
All this can’t handle every possible case you’d think should ideally work, because most of the patches are still made up of non-semantic, line-based diffs, but it can handle more of them. There’s a semi-formal introduction here with more details.
This makes a lot of sense now, thank you for the amazing write up. I’m currently working on a dvcs as well (lead-scm.org) and have been weighing the pros and cons of abandoning the project for an all-hands-on-deck effort on Pijul. ?
In general, a patch theory is developed and used to guide design of the merges/cherry-picks/etc.
If you want to guarantee something about the merge behaviour, patch theory helps you both in formulating the property you want and in verifying whether your tool has it.
I really want to give pijul a try, but unfortunately I cannot install it using cargo ): (I get an error when it tries to compile sanakirja)
You may have to use the nightly builds of rust. I was able to install pijul with cargo.
$ rustc --version
rustc 1.17.0-nightly (b1e31766d 2017-03-03)
It does not actually require nightly.
It appears I had previously built and installed rust manually, so… my mistake, sorry. And thanks for the hint!
What is the specific advantage of being patch based vs file/object based? I havn’t dug into pijul at length, but a familiar problem with git/hg that, e.g., ClearCase solved was renames by abstracting files out to first class objects.
Happy to read any academic research on the differences, btw. :)
I signed up for Pijul Nest but haven’t received the confirmation email. Is it broken or just slow?
It was caught in spam for me.
Aha, mine was too. Thanks!