Comparison to sapling (and maybe pijul)?

[hardliner66]

I was recently checking out git alternatives again and stumbled upon sapling, which derives many things from mercurial, which seems pretty nice.

Now I stumbled upon jj, which also seems really nice, but I'm not sure how they two compare to each other. What does jj offer that sapling doesn't and vice-versa. Same kinda goes for pijul, but with pijul I at least know that it's based on mathematical proof and is patch-based.

So for me it seems like jj is more similar to sapling, than to pijul, even tho it shares the first-class conflicts with pijul.

Would be cool if someone could give an overview comparison of sapling, pijul and jj.

[joyously]

The Pijul author pmeunier offered this on Zulip:

I can, but it's a rather personal take:

1. Sapling is a more or less hostile fork of Mercurial aiming at being compatible with Git. In other words, Git with better command names, and the exact same issues as Git. Speaking in terms of programming language, Sapling is to Git what C is to assembly.

2. Jj is a better git rerere, aiming at storing more metadata than rerere about conflicts. Since very few people realise the importance of having a good git rerere in Git itself, this is not made clear in the docs, since only experts in version control would see "a better rerere" and think "wow, this is cool".

{1, 2}. Merge is done via a heuristic assumed by many to yield exactly one unambiguous, correct result. This is not the case: merge is done using diff3, whose input lacks information to give merge a property many people expect: associativity. Associativity means that commits from a branch B can be merged one by one into branch A with the same result as merging the head of B into A.

{1, 2}. Commits change their identity after a merge, meaning that recovering a conflict resolution in a different context cannot use commit hashes, and must ressort to a heuristic to identify a conflict and see how it was solved in the other context.

3. Pijul is a sounder Darcs, also exponentially faster. Its internal model tries to match the way people think about work: in Git and Mercurial, you work with commits, but only ever look at changes/diffs. Pijul uses changes/difs, and shows you changes/diffs. Conflicts are modelled internally, instead of being "metadata attached to some of the failure case diff3 can detect" like in Git and Mercurial (and their descendants). The main feature is commutativity, which allows you to push conflict resolutions, bug fixes, cherry-pick, rebase… all with the same two intuitive commands: apply and unapply a patch. Unlike the commit-based systems, Pijul never needs to guess anything. In terms of programming language, Pijul is to Git what Rust is to C, and Darcs is to Git what Standard ML is to C.

[hardliner66]

Yeah, I already knew that pijul is mathematically sound and and the benefits that brings. So the main benefit from using pijul seems to be, better conflict resolution. Which is cool, but only part of the full story. Thanks for posting this.

[jhult]

Here are some more details on Pijul from its author:

Here's game-changing stuff:

• There's an example in the "why Pijul" page of our manual where Git completely reshuffles your lines, and no "custom merge algorithm" could possibly solve it. I would be terrified if I were working on crypto/security code and I knew my VCS was doing that: https://pijul.org/manual/why_pijul.html

• Patch commutation makes all big instances small: no need for submodules, partial/shallow clones, etc. Patch commutation lets you work on a small part of the repo by cloning only the patches you're interested in, and submit patches that mechanically commute with all patches on other parts of the repo.

• Free cherry-picking: no need for strict disciplines, you can just introduce a quick fix on your local work branch, and push just that to production. When you're ready merging the rest, you won't have to solve conflicts again (no need for Git rerere/Jujutsu/…)

• Many uses of branches reduced to "just use patches": many people, especially on fast-moving projects and "early days", don't really know what they're working on, and are dragged onto solving problems they didn't plan initially. Well, Pijul lets you focus on your work, then make patches, and then separate them into branches, thanks to commutativity.

• Separation of contents and operations: this really feels like the CSS3/HTML5 of version control. In Pijul, patches have two "detachable" parts, a part describing what the patch does (as concise as "I introduced 1Tb of data", i.e. just a few bytes), and the contents (not concise: the 1Tb themselves). You don't need the data to apply a patch, so when working on large files, you can record 10 different versions, and your co-workers will only download the parts that are still alive after that. No LFS required!

• Precise modeling of conflicts: conflicts are stored in our model, not "recorded" or "artificially first class". They're literally the core of our model, the initial theoretical motivation. Patches are where you need a good tool the most, and we record them and store your precious resolutions as actual patches, so they don't come back (no "git rerere" needed, and conflict resolutions can be cherry-picked).

Now, we also have less game-changing things like:

• Accurate and super fast "blame" (which we call "credit", and which doesn't require Pijul to look at the entire history like Git does).

• Generic diffs, and therefore merge, i.e. not necessarily line-based. We haven't implemented them, but you could in theory implement AST-based diffs on top of Pijul.

[martinvonz]

I don't think we want to add a Pijul comparison after all. See #3503

[martinvonz]

I've been asked before to write a doc comparing jj and Sapling before, so I'll try to write that doc now since you're also asking for it. I'll try to also write a comparison to Pijul. We also want a doc comparing to Mercurial. I don't yet know if it makes most sense combine those in one doc or one per tool.

[hardliner66]

Well, if you can fit a summary in a nice table to show multiple at once, that might be nice as an overview, but a deep dive into the individual differences would still be nice.

For instance, Sapling boasts with stacked commits. That's one of their main selling points. For jj it's only mentioned somewhere on the side (IIRC). So for someone just looking over those two would get the idea that sapling uses stacked commits, which isn't quite the default in git, but jj is more like a nice wrapper around git.

I know that this is not the case, because I looked a bit deeper, but as a first impression I don't really see why I should use jj over git. There is also a lot about what jj does, but (and I might missed it) nothing about why that's a good idea to do. For instance "The working copy is automatically committed". Okay, I get it's simpler, but is it what I actually want? Because some people might like the explicit commit of the working copy. So why is it more powerful?

And I'm sure some of that might be answered in more detail in one of the docs, but it would be nice to have that more upfront.

[martinvonz]

See if the documentation in #1716 helps explain the differences compared to Sapling, and maybe they answer your questions about differences compared to Git too. I haven't started working on doc comparing to Pijul yet.

[martinvonz]

And hopefully #1717 also helps a bit. Let me know otherwise.

[hardliner66]

I read through both docs and it's a clear improvement.

One thing that would be good to note is the integration of hosting services. I know Sapling can do sl pr submit to create stacked PRs, but that only works for github right now. Is there something similar in jj? And if yes, how does it integrate with gitlab for instance.

[martinvonz]

I added a bullet about that. I've never used sl pr, but I've told the Sapling folks about my documentation PR, so hopefully they will let us know if I didn't get it right.