When source control struggles under agent workloads, which part needs to change? The service distributing repository data, the division of work between client and server, or the history that developers collaborate through?
Our earlier comparison of Origin, Code Storage, and DeltaDB separated storage infrastructure from collaboration. Pando and Scion make the next question more concrete: how much of Git’s contract should a new system preserve?
These choices can coexist. A service can improve data delivery while a separate tool records richer history. Each changes a different part of the contract between a repository and its clients.
Keep Git, rebuild its service #
Pando preserves Git objects and workflows while changing how OpenAI serves its monorepo. Pushes stream packs into blob storage and publish ref versions through metadata transactions. Updates to unrelated refs proceed independently: readers get read-your-own-write consistency, but not a globally consistent view across branches.
Fetches reuse stored packs through packfile-uri and regional caches. Restricting which refs the server advertises during a push makes its pack easier to reuse, at the cost of sending redundant objects. Background compaction combines packs into larger covers. OpenAI reports nearly 80% lower median push latency; its interactive architecture comparison is a simulation, not a production benchmark. Pando runs internally, and the announcement discusses possible future sharing rather than offering a public service.
Continuity, the storage architecture behind Origin, also puts durable Git data in object storage. Its ordering authority is a write-ahead-log index. Cursor describes pushes as linearizable, while materialized Git repositories serve as warm caches that can catch up from the log. Idle repositories need no permanently hot replica.
The architectural distinction is where ordering and read work live. Continuity retains materialized repositories and an ordered log; Pando plans reads over reusable packs and coordinates writes per ref. Both preserve Git, but that compatibility leaves room for different consistency and caching choices.
Code Storage makes another decision explicit: expose repository infrastructure as a product for software. It offers Git over HTTPS alongside APIs and SDKs for creating repositories, writing commits, merging branches, and isolating refs. Its documented quorum architecture differs from Continuity, but the product question is independent of that implementation: does a caller want a forge, or programmable repositories beneath its own application?
Replace the repository model #
Scion moves computation to a server that clients are expected to reach. Anthropic’s system creates commits, performs merges and rebases, and answers history queries remotely. Clients keep bounded caches and fetch data on demand; no fully materialized repository exists even on the server.
Its changeset records files changed from the first parent, with pointers to content in blob storage. Creating changesets does not require moving refs; when a ref does move, it uses compare-and-swap on a Spanner row. This separates publishing new history from updating a shared name. Anthropic built the surrounding review and search tools too. The result is an internal system designed for its enormous monorepo, with online access as a requirement.
That is a larger migration boundary than replacing a Git host. A team must account for every tool that expects local history, a Git command, or an existing forge API. Removing work from clients is valuable only when the service and its integrations can take responsibility for it.
Lore illustrates a different reason to choose a new repository model. Epic’s design treats large binary content as first-class data, splitting files into content-addressed fragments and representing revisions as Merkle trees. The remote is authoritative, but clients can commit and branch offline when the required data is cached. Pushes upload fragments before conditionally advancing the remote branch pointer.
Lore is a public implementation; Scion is an internal deployment. Their shared use of central authority does not make their workloads or client contracts equivalent. In particular, Lore’s offline capability shows that replacing Git does not inherently require an always-online client.
Record the work between commits #
A faster checkout cannot recover a conversation that was never recorded. This is the separate problem addressed by DeltaDB: retain fine-grained edits and conversations together, with stable identities that references can follow as code changes. Replicated worktrees let people and agents collaborate before making a commit.
Delta, the application built on it, still commits and pushes to an existing Git repository. That makes Git an interoperability boundary for a richer collaboration record. Someone outside Delta can consume the resulting commits without participating in the live session.
Manyana explores a narrower question through a CRDT-based demo: can merging always produce a convergent result while still drawing attention to overlapping edits? Its weave retains lines and their history, allowing merges without searching for a common ancestor. Potential conflicts become information to review rather than a failure to produce a merged state.
This is an experiment in merge semantics, not a hosted alternative to Pando or Scion. It also highlights a distinction worth preserving in any collaboration system: convergence means participants agree on a result. It does not mean the resulting program expresses the right intent. Review and testing still have a job.
Compare the decisions #
Read together, these designs suggest five decisions to make explicit when evaluating source control.
| Decision | Examples | Question to carry forward |
|---|---|---|
| Preserve Git, change its serving architecture | Pando, Continuity | What must be ordered together, and which bytes can readers reuse? |
| Make repositories programmable infrastructure | Code Storage | Which operations should an application perform without a checkout? |
| Change the repository and client contract | Scion, Lore | Which operations stay local, and which require the authority? |
| Retain edits and conversations | DeltaDB | What context must survive beyond a published snapshot? |
| Make merging converge by construction | Manyana | How will people inspect and resolve competing intent? |
A fleet creating temporary repositories and a team driving one enormous monorepo can both be described as agent scale. Their storage lifetime, contention, and checkout patterns may be very different. Likewise, a live collaborative worktree is solving a different coordination problem from thousands of independent branch pushes. The workload has to come before the architecture.
What this means for jj #
Jujutsu separates commit storage, operation storage, operation heads, indexes, and working copies behind interfaces. That separation matters here: changing where bytes are stored need not dictate how a user identifies changes or recovers repository operations.
The jj roadmap describes Google’s internal database-backed service, which stores commits and operation logs in the cloud with a local caching daemon. A similar public server remains a roadmap goal. It is evidence that jj’s model can extend beyond Git storage, not an integration that JayJay can already offer.
For a Git-backed jj repository, a new Git service must still work with the transport capabilities of the client in use. Preserving Git’s object model alone does not establish that compatibility. Nor does sharing commits and refs imply sharing the local operation log or the complete identity and evolution of a jj change.
For JayJay, the useful direction is to keep those boundaries explicit: repository transport, forge review, and live collaboration are separate integrations. A faster remote can improve an existing workflow. A different history model needs a deliberate account of which identities, discussions, and recovery paths survive the crossing.