Listen to this article
AI may have been used to generate this audio.
Press Space or K to play or pause, and J or L to go back or forward 15 seconds.Sources checked on 16 October 2026.
On 13 October 2026, Anthropic described replacing Git in its monorepo with Scion, a version control system it built internally. It updated the account on 15 October. [1]
For most teams, Git remains an excellent default. It lets people develop independently, keeps a useful history alongside the code, and supports collaboration without making every contributor dependent on one machine. An application team does not need to retire those advantages because a frontier AI company found a different set of trade-offs worthwhile.
Git’s history helps explain that choice. It shows why the design works so well, where its assumptions become expensive, and how much can change around it before replacing it becomes necessary.
Git began with Linux losing its tool
Version control records how files change, so people can compare versions, combine work and recover earlier states. Before Git became widespread, centralised systems such as CVS and Subversion organised that work around a server. Developers checked out files, made changes and committed back to the shared repository. The server held the authoritative history. [2]
Linux had already moved towards a different arrangement. After years of exchanging patches and archives, the kernel project began using BitKeeper in 2002. BitKeeper was proprietary, but its distributed model allowed developers to work with repositories of their own. In 2005, the relationship broke down and the free-of-charge arrangement ended. [3]
The dispute involved Andrew Tridgell’s reverse engineering of BitKeeper’s protocol. In a later interview, Linux creator Linus Torvalds recalled trying to mediate before deciding he could no longer continue with it. He also had no appetite for returning to the earlier workflow. The alternatives he examined failed his requirements for performance, integrity and distributed development. [4]
Figure 1. A chronology of design choices. The 2005 events are separate milestones; the gaps are not a time scale. Sources [3] [5] [14] [1]
On 7 April 2005, Torvalds made Git’s first commit. The implementation could already record its own development. [5] Within roughly ten days, he was using it for a kernel commit. That often gets compressed into the story that Git was “written in ten days”, but the early system was a starting point. Torvalds had spent time thinking through the design before writing it. [4]
One of the useful ideas he took from BitKeeper concerned permission. Give developers their own repositories and they can record and organise work before anyone grants them access to a shared main line. Maintainers still decide what to accept. Creating a change and accepting it into the project become separate decisions. [4]
The next part of the history deserves more attention. Junio C. Hamano took over as maintainer at the end of July 2005. In his account of those early months, the project still had substantial gaps to fill, and contributors were working through competing approaches. [6] The Git people use today owes a great deal to that continuing maintenance. In the twentieth-anniversary interview, Torvalds emphasised how little of those twenty years he had personally spent on it. [5]
GitHub launched publicly on 10 April 2008. [7] Its contribution sits at another layer: hosting repositories and giving people a place to propose, discuss and review changes. Pull requests bring conversation, checks and code differences together around a proposed merge. [8]
Keeping those layers separate helps with the current debate. Git provides the version history and the machinery for exchanging it. A hosting service supplies much of the experience a team builds around that history. You can change the review process, the automation or the host without necessarily changing the version control system.
What a local repository buys you
Git models a commit as a snapshot of a project. Unchanged file contents can be reused across snapshots; each commit does not require another complete physical copy of every file. In an ordinary full clone, history and the objects needed for local work are available on your machine. Examining changes or making a commit does not normally require a round trip to a server. [9]
Figure 2. A conceptual commit graph, shown from earlier to later. This example uses a merge commit; Git also supports other integration workflows. Sources [9] [10]
A branch is a lightweight reference to a commit. Creating one does not copy the whole project. Commits record their parents, so Git can track where development diverged and find a common starting point when combining it again. [10]
These are useful properties for fairly ordinary work. Imagine a small team changing its checkout flow. One developer tries a new interface while another investigates a payment bug. They can keep separate lines of development and compare their changes before integrating them. The repository records what changed; the team still has to decide whether the combined behaviour is correct.
Local history also makes the working environment less fragile. With a full repository available, a temporary network failure need not stop someone inspecting previous changes or saving new commits. [9] Publishing and coordinating with colleagues still require a connection, but a substantial part of development can continue.
There is a practical freedom here. A source repository can outlast the particular service hosting it. Moving it does not automatically move every issue, review comment or platform setting, so changing hosts still takes work. Even so, retaining control of the code and its history is a valuable starting position. It is worth including that independence in the cost comparison when considering a replacement.
Large repositories have always needed special treatment
The costs change when the repository becomes enormous and thousands of short-lived jobs need access to it.
Consider the difference between a workstation that reuses data day after day and a disposable job that starts without a useful cache. The second may spend much of its life obtaining files and history before doing its actual task. A workload dominated by those jobs gives an infrastructure team a reason to minimise what each client downloads and computes. Git’s partial and shallow clone options already address parts of that problem. [11]
The choice also depends on how a company organises its code. A monorepo keeps multiple projects in one repository. That can make coordinated changes easier, while concentrating more history and activity in one system.
Long before today’s coding agents, Google was documenting this trade-off. Rachel Potvin and Josh Levenberg’s 2016 paper described Google’s custom source repository and the supporting systems that made a shared codebase practical for tens of thousands of developers. [12]
Meta took another route. When it open-sourced the Sapling client in November 2022, it described a decade of work on the system. Its internal setup combined a client, a compatible server and a virtual filesystem to support a repository with tens of millions of files and commits. Sapling had begun as an extension to Mercurial before developing its own formats and protocols. The public client could also work with Git repositories. [13]
Large organisations were already making these choices. Their experience gives smaller teams useful techniques to borrow, but the size and shape of the workload still determine which techniques are worth operating.
What Anthropic built
Anthropic says daily merged changes rose from roughly 2,500 in May to over 30,000 in September. A compressed working copy exceeded 25 GB; CI performed about 25 million code checkouts daily. It had already tried partial and shallow approaches, repository snapshots and hundreds of Git mirrors. [1]
Figure 3. Company-reported observations, not a reconstructed daily series. May is approximate; September is a lower bound. Timeline events are evenly spaced. Sources [1] [14]
Most clients were already agents and online jobs. Scion makes that connectivity a design assumption. Servers handle commits, merges and history queries; clients request needed data. Jobs can use APIs without maintaining local repositories. Seven engineers built Scion, the Antique review tool and related systems, completing the migration in five months. [1]
Figure 4. Simplified responsibility diagram. Git here means a full clone with the needed objects already local. Scion follows Anthropic’s always-online design; this is not a benchmark. Sources [9] [1]
Anthropic reports a 200-fold reduction in CPU and memory requirements compared with its previous Git mirroring infrastructure. That is a result for its own deployment, not a general performance comparison. Adoption elsewhere requires changes to review, search and CI. Anthropic explicitly says Scion is unsuitable as a general Git replacement. [1]
The AI boom is showing up in GitHub’s traffic
GitHub’s 6 October report describes the scale behind the change. September 2026 brought 7.38 billion commits, more than five times the volume a year earlier. Pull request merges reached nearly four times their year-earlier volume. These are different measures: commits record states; merged pull requests integrate proposed work. One pull request can contain many commits. [14]
Figure 5. Relative growth uses the prior-year volume as 1×. The arrow marks a lower bound; the hatched bar marks an approximation. The report does not give an absolute PR-merge count. Source [14]
GitHub links the pressure to developers and agents working concurrently. Its figures do not isolate the fraction caused by AI or measure how much useful software resulted. More commits can mean more checkpointing; more merges can mean smaller changes. The volume is real, but it is not a productivity score.
The chart keeps the published qualifications. The commit value is a lower bound; the pull-request value is approximate. No exact earlier commit count or absolute count of merged pull requests is supplied in this report. [14]
GitHub is changing what sits behind Git
GitHub’s redesign separates storage from compute, moves authoritative data to Azure Blob Storage, and reduces coordination around writes. It intends to preserve Git semantics and existing workflows. The work is in progress. [14]
That offers a useful distinction for anyone deciding what to adopt. A service can change substantially behind a familiar interface. More automated activity may require new storage and serving architecture without requiring every developer to learn a new version control model.
It also leaves room for an ordinary product team to benefit from infrastructure work it would never sensibly fund itself. The question is whether the service meets the team’s needs at an acceptable cost, including the controls and reliability the team depends on.
The improvements most teams can make now
A team using coding agents has several options inside the Git ecosystem before it needs a replacement.
Figure 6. These options act on different parts of the workflow. A local experiment and measurements should decide whether they help. Sources [11] [15] [16] [17]
Start by naming the specific delay or failure. “Git is slow” can describe a large download, too many files on disk, a difficult merge, or a change waiting for someone to review it. Those need different responses.
What the team is experiencing | An option to investigate | What it changes |
|---|---|---|
Concurrent tasks interfere with the same working files | Git worktrees [15] | Separate working directories and branches attached to one repository |
CI retrieves history it never uses | Shallow clones [11] | Limits the history downloaded; jobs needing older commits require care |
A clone fetches file contents before they are needed | Partial clones [11] | Defers selected objects until required, with server support |
A developer needs only part of a monorepo | Sparse checkout [16] | Limits the files present in the working directory |
Large binary assets inflate the source repository | Git LFS [17] | Keeps pointers in Git and stores the large contents separately |
These features address different layers. Sparse checkout controls the working files; partial clone controls which objects are obtained. They can be useful together, but selecting fewer folders does not by itself mean the repository’s historical data was never downloaded. [11][16]
Worktrees are particularly relevant when several tasks run at once. An agent can work in one directory while a developer uses another, with both attached to the same repository. That avoids giving every task an entirely separate repository copy. It does not settle conflicting changes when the work comes together. [15]
The review process deserves its own attention. A change sitting unread for two days will not reach production much sooner because a clone became a few seconds faster. Smaller changes, clear review ownership and tests that finish reliably are reasonable interventions to try before replacing the system holding the history.
Git’s command line is also open to criticism. A team that finds another interface easier should evaluate it. Jujutsu, for example, uses Git repositories for storing commits and files while offering a different model for working with changes. It can exchange work with Git remotes. [18] Trying that approach is a much smaller commitment than taking responsibility for a new source-control service and everything around it.
Keeping Git leaves considerable room to improve how people use it.
A migration needs a problem of its own
“Git is perfect for 99.999% of us” is an opinion, with rhetorical decimal places. The defensible claim is that Git is an excellent default for ordinary software development. It is worth replacing when another system solves a concrete problem well enough to pay for the transition and its continuing operation.
That judgment includes the unexciting work. Somebody has to maintain integrations, teach the workflow, investigate broken automation and recover from mistakes. A cheaper implementation does not remove those responsibilities.
A migration should earn its place by removing a measured bottleneck.
For a team considering a migration, I would first collect a week of timings from the current process. Separate repository access from building, testing, review and deployment. Record how much time jobs spend fetching data, how frequently repository operations fail, and how long completed changes wait for a decision. Look at the busiest periods as well as averages.
Then estimate what the proposed replacement would actually remove. If repository access consumes a large and growing share of compute or blocks useful work, test an alternative against that workload. Include the cost of operating it and the tools that would have to change.
If repository operations are already fast, I would leave Git in place and spend the next week reducing failed builds, oversized changes or time waiting for review. Measure whether more completed work reaches users before committing to a larger infrastructure project.
Sources
Primary documentation, original announcements, and interviews. Figures retain the dates, units, and qualifications in the sources. Checked on 16 October 2026.
Anthropic — Redesigning source control at Anthropic. 13 October 2026; updated 15 October.
Pro Git — About Version Control. Background on centralised and distributed version control.
Pro Git — A Short History of Git. Linux, BitKeeper and Git’s original design goals.
The Linux Foundation — 10 Years of Git: An Interview with Git Creator Linus Torvalds. 6 April 2015. Torvalds’s account of the dispute, early implementation and distributed workflow.
GitHub — Git turns 20: A Q&A with Linus Torvalds. 7 April 2025. First commit, early design and long-term maintenance.
GitHub — Celebrating 15 years of Git: An interview with Git maintainer Junio Hamano. 7 April 2020. Hamano’s account of taking over in July 2005.
GitHub — We Launched. Original public launch announcement, 10 April 2008.
GitHub Docs — Pull requests. Review, discussion and checks supplied by the hosting platform.
Pro Git — What is Git?. Snapshots, reused file contents and local operations.
Pro Git — Branches in a Nutshell. Commit ancestry and lightweight branch references.
Git reference — git-clone. Shallow history and partial-clone filters.
Google Research — Why Google Stores Billions of Lines of Code in a Single Repository. Rachel Potvin and Josh Levenberg, Communications of the ACM, 2016.
Meta Engineering — Sapling: Source control that’s user-friendly and scalable. 15 November 2022. Internal scale, development history and Git-compatible client.
GitHub — Building Git infrastructure for agent-scale development. Published 6 October 2026; updated 7 October. GitHub’s reported activity, growth comparisons, and infrastructure redesign in progress.
Git reference — git-worktree. Multiple working trees attached to one repository.
Git reference — git-sparse-checkout. Limiting the files materialised in a working tree.
GitHub Docs — About Git Large File Storage. Pointer files and separately stored large objects.
Jujutsu — Project README. Git storage, interoperability and a different version-control interface.
One email when we publish. Research, product decisions, and what teams report back.
