Why companies are rethinking Git

← All field guides

Updated 3 November 2026: expanded the scaling context and added Cursor’s documented systems and a separately labeled OpenAI report.

Why this is getting attention now

Source control is becoming a more visible part of the AI engineering conversation. An agent may inspect a repository, create a workspace, try a patch, run checks, and abandon the attempt. Multiply that workflow across many agents and the cost of preparing and coordinating work becomes worth examining.

Recent examples include Cursor’s August 2026 account of Continuity and Origin, followed by Anthropic’s Scion announcement and GitLab’s next-generation source-control update, both published on 13 October 2026. These describe different responses to growing automated workloads. Anthropic’s report · GitLab’s update.

Google and Meta supply an older engineering lineage. Microsoft supplies a useful example of investing in Git itself. Jujutsu adds another direction: changing the developer workflow while retaining Git interoperability. Together, these cases explain why “companies building their own Git” covers several distinct decisions.

Scale was already a problem before AI agents

Git scaling challenges predate the current wave of coding agents. In its 2017 Windows migration report, Microsoft described about 3.5 million files, a roughly 300 GB repository, and around 4,000 engineers. File count, repository size, and activity each created difficulties. Microsoft addressed them through GVFS and Git enhancements. Source: Microsoft’s Windows migration report.

There is also a server-side problem: serving many concurrent Git operations while keeping repository copies consistent and available. Cursor’s engineering account explains why scaling Git hosting requires more than adding web servers. Source: Cursor’s hosting architecture.

Our assessment: AI agents amplify these existing pressures by repeatedly preparing workspaces and generating changes. It helps to separate three measurements: repository size and file count, simultaneous reads and writes, and the rate at which changes can be reviewed and merged. Each can demand a different remedy. The examples below show a range of responses, from improving Git and its hosting to building a custom source-control system.

Who is building what?

Dates identify the evidence discussed here, not necessarily a project’s launch. Status was checked on 3 November 2026. Scroll the table horizontally on smaller screens.

Cursor: Origin hosting, powered by Continuity

Cursor’s 18 August 2026 engineering report describes Continuity, its own Git storage system, and Origin, its repository-hosting platform. Continuity keeps the durable record of pushes in a write-ahead log in S3-compatible object storage. Local Git repositories act as caches that can be reconstructed from that log. This retains ordinary Git repositories while changing how the hosting infrastructure stores and recovers them. Source: Cursor — Git at any scale.

Origin’s documentation covers repository creation, code browsing, pull requests, and GitHub mirroring. It describes beta access and makes an important distinction: Origin is authoritative for Origin-hosted repositories, while GitHub remains authoritative for synced repositories. Mirroring a repository into Origin therefore does not by itself move its source of truth. Source: Origin documentation.

OpenAI: reported development, with launch status unverified

In March 2026, reporting described OpenAI developing a GitHub alternative after service disruptions. The coverage attributed the information to The Information. Source: Tom’s Hardware, reporting on the project.

Evidence limit: this review did not find an official architecture announcement or verify a public launch as of 3 November 2026. We include it as a reported project to watch. A hosting-platform report alone does not establish that OpenAI has replaced Git’s underlying version-control model.

Anthropic: a bespoke system for a demanding workload

Anthropic reports that daily merges rose from roughly 2,500 in May 2026 to more than 30,000 in September. It says it migrated its monorepo to Scion in five months and built related review, search, and access-control tooling. Source: Anthropic, 13 October 2026, updated 15 October.

Scion moves operations such as history queries, commits, and merges onto servers. Clients retrieve the data they need, and some automation can work through APIs without a checkout. The design assumes online clients and a very large monorepo.

Anthropic explicitly says Scion is unsuitable as a general-purpose Git replacement. Adoption would also involve the surrounding development infrastructure. This is an internal case study, not an announcement of a broadly available product. Its reported results describe Anthropic’s environment, not a benchmark of what another team would gain. Architecture and adoption limits.

GitLab: redesign the backend, retain the ecosystem

GitLab’s October update describes stateless compute over shared object storage, with interfaces that let agents obtain files and history without repeatedly cloning a repository. It intends to retain the Git protocol and connect agent work to existing merge requests, CI, and governance. Source: GitLab, 13 October 2026.

The distinction matters: this is a Git-compatible infrastructure direction, rather than an internal-only replacement. GitLab calls the system a private beta in that announcement, and its early-access page continues to describe preview capabilities. It also labels its performance figures as early internal results. Treat availability and benefits as things to validate with the vendor and your workload. Current early-access page.

Meta: separate the client, server, and working copy

Meta’s stack makes the layers tangible: Sapling is the source-control client, Mononoke is the server, and EdenFS provides a virtual filesystem for checkouts. Mononoke’s documentation describes a VCS-independent data model, Bonsai, that can serve both Sapling and Git clients. Source: Mononoke documentation.

There is also a support distinction. The public Sapling repository describes Mononoke and EdenFS as buildable for unsupported experimentation; public source does not imply a turnkey, externally supported replica of Meta’s infrastructure. Source: Sapling repository.

Meta’s 16 October 2025 engineering post describes directory branching: teams can manage versions of a part of the monorepo while keeping the repository-level commit graph largely linear. That is a concrete workflow change motivated by monorepo scale, and it predates the October 2026 announcements. Source: Branching in a Sapling Monorepo.

Google: the internal monorepo precedent

Google’s 2016 research describes a custom source repository supporting a shared codebase and large engineering population. Its software-engineering book discusses Piper and the policies around version control and branch management. This is longstanding infrastructure, not a newly launched response to coding agents. Source: Google Research, 2016 · Version Control and Branch Management.

For readers considering a similar approach, the useful lesson is the coupling between tooling and engineering practice. A shared repository affects dependencies, ownership, testing, and how changes are coordinated. Copying a repository design without examining those practices would leave much of the operating model unspecified.

Jujutsu: another workflow over Git-compatible storage

Jujutsu, invoked as jj, separates its user interface and version-control algorithms from storage. Its Git backend can exchange ordinary Git commits with existing remotes. Features include a working-copy commit, operation history, and automatic rebasing of descendant changes. Source: Jujutsu project documentation.

The project describes Google as a major contributor while explicitly saying it is not a supported Google product. It should therefore not be presented as a newly announced proprietary Google replacement for Git. It is an open-source project that offers a different working model, with compatibility limits and workflow changes to evaluate. Project status and Google disclaimer.

Microsoft: a historical example of scaling Git

Microsoft’s May 2017 report on moving Windows development to Git describes GVFS, the Git Virtual File System, and Git enhancements. The approach downloaded needed portions of the repository on demand instead of materializing everything up front. Source: Microsoft, 24 May 2017.

This is included as historical context, not a current product recommendation or a new 2026 launch. It demonstrates that improving how a working copy is populated can address scale without abandoning Git’s ecosystem.

What this means for an engineering team

Our assessment: these examples point to more experimentation at the boundaries of source control—how much data a worker needs, where operations execute, and how concurrent changes reach review. They do not establish that ordinary repositories need a new VCS.

Before evaluating a migration, collect evidence from the workflow you actually run:

1. Time workspace preparation separately. Distinguish repository access from dependency installation, build setup, and model execution. A slow agent run is not automatically a source-control problem.
2. Measure repeated work. Record bytes fetched and time spent preparing fresh attempts. Compare a warm workspace with a cold one, using the same revision and task.
3. Test concurrency, not just one fast checkout. Include simultaneous workers, failed attempts, interrupted operations, and conflicting changes. Check that evidence and authorship remain attributable.
4. Preserve the review contract. Verify which revision was tested, what changed before merge, and who approved it. More commits are not a substitute for a correct, reviewable result.
5. Count migration dependencies. Include code search, access controls, CI integrations, backup and recovery, developer training, and a rollback route in the cost of a replacement.

A useful pilot starts with one representative repository and a measurable problem. Decide the acceptance criteria before trying alternatives. If the bottleneck is review latency or a slow test suite, changing version control may simply leave the dominant delay untouched.

Reading notes and sources

This is a curated review of public engineering reports and project documentation, with OpenAI’s reported project explicitly attributed to news coverage, checked 3 November 2026. Company results are self-reported. We have not benchmarked these systems. Earlier systems are included to explain the architecture’s history; this is not an exhaustive catalog of version-control products.

• Cursor — Git at any scale (18 August 2026), plus Origin documentation.
• Tom’s Hardware — OpenAI’s reported GitHub alternative (March 2026; news coverage, not an official product announcement).
• Anthropic — Redesigning source control at Anthropic (13 October 2026; updated 15 October).
• GitLab — Scaling Git for the agentic software factory (13 October 2026), plus early access.
• Meta — Branching in a Sapling Monorepo (16 October 2025), Sapling source and support notes, and Mononoke architecture documentation.
• Google — Why Google Stores Billions of Lines of Code in a Single Repository (2016), plus Software Engineering at Google, chapter 16.
• Jujutsu — README, Git compatibility, and project status (living documentation).
• Microsoft — The largest Git repo on the planet (24 May 2017).