This presentation details the architecture, current status, and future roadmap of Google's internal integration of the Jujutsu (JJ) version control system. The system is designed to work with Google's massive monorepo, "Piper," by leveraging a custom, centralized backend called the "Commit Cloud," which stores all commits and repositories transparently. The architecture features custom backends, a performance-enhancing local daemon that proxies requests, and a specialized revset engine highly optimized for Piper's long, linear history. The talk covers the custom commands used to interface with Piper's "Change List" workflow, the use of JJ's bookmarks for code review management, and positive early feedback from its 900+ beta users. The ultimate goal is to migrate all of Google's ~100,000 developers from existing systems (Mercurial-based and the native Piper CLI) to JJ, providing a unified and modern version control experience.
Jujutsu at Google: Architecture and Future Plans
0:24 Current Status and Roadmap: The project is in open beta with around 900 internal users. A General Availability (GA) release for Linux is planned for early 2026, after which Google will begin migrating its ~100,000 developers from their current Mercurial-based system ("fig") to JJ.
1:53 Custom Client and Backends: The JJ client at Google uses custom backends for commits, the working copy, and a Virtual File System (VFS) integration to interact with the monorepo. It is built internally with Blaze instead of Cargo.
3:13 The "Commit Cloud": All commits and repositories are stored in a central database called the "Commit Cloud." This allows commits to be shared across the company and repositories to be accessed from any machine. Commits are uploaded automatically and transparently in the background.
4:52 Integration with Piper Monorepo: JJ is integrated with Piper, Google's centralized, Perforce-like version control system. Piper's immutable "submitted CLs" are treated as the mainline history, while mutable "pending CLs" are used for development, similar to branches.
8:45 System Architecture Overview: The system consists of the JJ CLI on the user's machine, a local daemon that caches objects and batches requests for performance, and a cloud-based server that interacts with the "Commit Cloud" database. An indexer service continuously imports new mainline commits from Piper into the Commit Cloud.
10:13 Custom Commands for Workflows: The integration includes several custom commands to manage the Piper workflow:
jj piper sync: Fetches the latest mainline changes and rebases local work on top.
jj piper upload: Creates a pending Piper Change List (CL) for code review from a JJ commit.
jj piper patch: Imports a pending Piper CL into JJ as a commit.
12:29 Code Review with Bookmarks: The system uses JJ's local and remote bookmarks to track the relationship between a local commit and its corresponding remote Piper CL, enabling a robust code review workflow. A common pain point is that jj split currently moves the bookmark to the wrong commit.
20:39 Highly Optimized Revset Engine: Google uses its own custom revset engine, not the upstream one. It is specifically optimized for the monorepo's structure: one extremely long, linear history with many small, short-lived branches. This allows it to efficiently query ranges of millions of commits.
26:53 Positive User Feedback: Early feedback is overwhelmingly positive. Users praise the speed, first-class conflict resolution, undo functionality, and general history editing capabilities.
28:51 Future Plans for Unification: The long-term plan is to make JJ the single, unified interface for version control at Google. This involves deprecating the existing Mercurial integration (fig) and the native Piper CLI, and eventually enabling code reviews to happen directly on JJ commits in the Commit Cloud.