Pijul is a free and open source (GPL2) distributed version control system

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.

Newbie jj convert here.

jj is not patch based, like pijul, but snapshots, like git.

A sibling commentor points out the change id stored by jj: it is true that at the moment, this isn't really exportable to git in a native way. However, there is a path forward here, and it may come to pass. Until then, systems like Gerrit or Phabricator work better with jj than systems like GitHub.

However, all is not lost there either: tooling like spr[1] allows you to map between the two universes.

At my job, at least one person was using jj for six months at work without any of the rest of us being the wiser. Some of the rest of us are trying it out. A really nice thing about jj is that you can use it without anyone else needing to, thanks to the git interop.

1: https://github.com/getcord/spr

- Large/binary files: Pijul splits patches into operations + contents. You can download a patch saying "I added 1Tb there" without downloading any single byte of the 1Tb. No need to add any extra feature.

- Large projects: Pijul solves that easily using commutativity, you can work on partial repos natively, and your changes will commute with changes on other parts of the monorepo.

> No need to add any extra feature.

Well that's the building blocks, but Git can do that through blob filters and whatnot. It's a necessary foundation but not a complete feature. You need ways of recording which blobs should be fetched eagerly, which should be fetched on demand, maybe a way to indicate where to get the data (you might want a central store for big files like LFS).

> you can work on partial repos natively

That's very good. Does it have anything like submodules or subtrees? I kind of think they are a bad idea in general but people do use them and they can be useful in very niche cases. From the sounds of the patch-based system I guess you could do subtrees quite elegantly? Can the patches be given a "base directory"?

I don't want to seem like all this stuff should be done immediately but it does feel like these are things that kind of need to be integrated from the start to work properly, unlike in Git where they've been tacked on badly.

I'll give magit a try. But imagine if you had to use TEX to format anything more than trivial documents. It makes me want to get a Vision Pro and see if a direct manipulation git UI could access the full potential but with visual discoverability and safety.