Is There Life Outside of Git?

Yes. Much more than you think. Google, Meta, and (as of October 2026) Anthropic roll their own in-house version control. Why? Because of scale, mainly.

There are so many version control systems, many of which we won’t be dealing with here (looking at you Mercurial), that JJ was born. A brand new VCS which uses git as its storage layer. JJ is built from the ground up to fix the warts in git (if you completely get git probably you are too clever for this article) or in any version control system you happen to use while remaining compatible with it. Said differently, you can use JJ and still use GitHub.

JJ: The Shiny New Version Control System (For All of Us)

Jujutsu (JJ)’s main purpose is revisiting git design to better propagate merge conflicts, reducing the burden on developers. This is done by having the working copy (what you are currently doing) automatically committed so you can get rid of the staging area. This means no more friction when moving between branches. Ah, almost forgot, branches don’t exist either (but bookmarks mimic them for git compatibility and remote branch tracking). Everything is commits and their hierarchy.

The best thing about all of this is that this stays git compatible so you can start using it today, in any git forge (more on this in a later article).

Piper and Sapling: How Google and Meta Store Billions of Lines of Code in a Single Repository

Why a monorepo? Tens of thousands of developers around the world have a single source of truth.

Why not a monorepo? Because git is not very efficient when you start versioning billions of lines of code. But, probably, in the billion lines of code range you can also afford to roll your own version control system.

Piper is Google’s solution to the humongous monorepo problem. Piper is a centralized VCS distributed over multiple machines with a high level of redundancy so that Google employees all over the world can access the codebase as efficiently as possible. Piper also solves another very important problem, secrecy (or as they like to call it, security). Through Piper you can get file-level access control so that business critical algorithms are not exposed to thousands of developers in unrelated areas. On top of access control, you also get an audit log so that you know who read what, especially in case of compromised files where sensitive data has been committed.

Everything works through workspaces, which git would call a clone (or working copy to be more specific). The main difference is that Piper accommodates new code only after code review, so there is no real concept of branch. Developers access code through clients in the cloud so the huge repo never gets cloned but everyone works on virtual file systems. The idea is that these clients only store the modified files so each developer does not take up too much memory.

So what’s Sapling? It’s much of the above but open source. So, we have far more info on the inner workings of the beast. Especially differences with respect to git:

1. Sapling does not require or encourage using named local branches (JJ anyone?).
2. Sapling has no staging area. But still has a git commit/amend mechanism we don’t find in JJ (at least not under this name).
3. On-demand fetch of files and data (much like Piper).

These, and many more I left out here, are version control system features. Some of the features we saw above for Piper are implemented on the version control server which holds the actual data and can enforce access control, secrecy, and provide redundancy. There is an open source implementation of a server too called Mononoke.

Scion: Anthropic Does Sapling but for Agents

Why is Anthropic not using Sapling? Agents, I guess.

They start from a simple assumption: agents write most of the code and they are always online. Git clones are meant for offline work that an agent does not require.

The main ideas are exactly the same as Piper and Sapling, as they acknowledged in their recent article. They liked Sapling so much that they (or whatever machine) called their data model Bonsai.

As they quite clearly put it, they move all the diff and history computation on the server so that a single developer does not need much data to be able to work with a large repo. Like in Piper, they go as far as having commits happening on the server so that on the developer side the very bare minimum of info is needed. The only important bit is constant access to the server.

A user or an agent must always be able to ask for a partial checkout of the repo or simply get a diff between two files directly from the server.

Conclusion

Git is here to stay but new approaches have been coming up in recent years. The pattern is one of scale pushing a company to develop new ways of versioning internal code; JJ breaks this pattern a bit. I don’t know if developer experience will still be so important in AI coding but it’s cool to see a refreshing take on a 20-year-old version control system.