Still alpha software, so tons of roughs edges, but the potential is incredible. I think it'll be similar to the centralized -> distributed revolution that git ushered in.
and the linked "badmerge" example:
Have you ever had to laboriously cherry-pick a series of commits solving some bug between branches (e.g., from stable to dev or vice-versa)? It's painful, and then later on you get conflicts because when you cherry-pick, git doesn't "understand" what's happening. Pijul solves that.
At a fundamental level, imagine I'm editing two files A and B, that have nothing to do with each other. Because git's level of dependency is the entire repo, if I switch back and forth between editing A and B, git inserts a series of arbitrary and not-actually-real dependencies between those edits. Then, as a consequence, there's no easy way for me to decide, say, I would like to merge my changes to A somewhere, but not my changes to B.
Or how about the entire controversy(/complexity) of whether to rebase or merge when pulling? The choice is an artifact of git's model, really a question of "in which way would we like git to represent some not-real constraints". This difficulty doesn't exist in Pijul, where dependencies are more fine-grained and real.
Another pain point you may have hit w/ git is when you do a merge, but somehow actually the changes were not included; this usually happens as a result of confusion regarding a conflict. Then you have to do painful repo surgery to try to convince git to actually include the changes you want.
In general large conflicts are quite painful in git: for the duration of the conflict, you are in a special state, and cannot commit. In pijul, conflicts are a first-class state of the repo, so you can iteratively work towards resolving your conflicts, using all of the normal VC tools to checkpoint along the way.
Disclaimer: I've only played with Pijul, not used it in anger. I definitely see a lot of potential though.
The main thing I believe is intrinsically superior to Git (I use Pijul a lot) is patch commutation, not just patches. Pijul guarantees that two patches that could be written independently always commute.
This has important consequences:
- You can push patches from the same branch in any order (provided they don't depend on each other). This wont change their identity, meaning that if you decide to push the other patches later, you can do it without having to rebase, and review/test the new order.
- Conflicts happen between patches, and conflict resolutions are modeled as patches. This means that if you solve a conflict once, you can push your resolution, even if you have your own, private patches on the same branch.
https://nest.pijul.com/pijul/pijul/changes/XTMYHJZLWWT5I2PJA...
First, there are explicit dependencies, and also each section starts with a somewhat cryptic machine-readable description, for example:
B:BD[2.1195] → [2.1195:1291]
One of the challenges in the new version of Pijul was to find a description that was printable in text, and not too-unintelligible to humans.
Darcs isn't alpha, but merges patches in exponential time, which was the initial motivation for Pijul.
I've also been really happy with Darcs, expect for two things:
- Conflicts are not handled very well, as if they were not properly stored internally. `darcs revert` on a conflict doesn't always do what I expect.
- The fact that it doesn't scale (even with the quadratic algorithm) means that big users can't adopt it, which means that too few people write tools for it (including a hosting website: I'm aware of hub.darcs.net, but there are many things missing, including on security). Darcs is hard to install on platforms such as Windows. Also, few people know it, which means that it's hard to collaborate using it.
I just set up Trac for Darcs hosting -- though it has some tension with the Subversion model -- exporting to git for people who want the pain. I'd investigate Sourcehut integration if I had the time.
When we say "Pijul is patch-based", we don't only mean that it stores patches, but rather that patches that could be written independently commute, meaning that they can be applied in any order, and are guaranteed to give the same result in all cases (including when they conflict).
This simplifies many workflows.
What's that rebase/cherry-picking craziness?
I can only guess what OP had in mind: when you rebase in Git, commits are "replayed" on top of other commits. But there's no way this replay can really work, for two reasons:
- conflicts are not even modeled in commits, which is why some solve conflicts can come back. You may say this never happens, but (1) the problem is so real that Git even has a `git rerere` command to fix it, and (2) many workflows have explicit ways of avoiding this situation: no matter what your natural workflow is, you must adapt it to suit Git.
- each step of the replay tries to commute patches, but Git uses 3-way merge for that, and this is not a 100% algorithm, merely a heuristic, as explained there: https://pijul.org/manual/why_pijul.html