Why large tech companies rethink Git, and should we?

Reading Anthropic's post about rebuilding source control brought back a familiar question. Google has its own system, and Meta has developed tools that differ from Git. As coding agents produce more code, should we change ours too?

I manage dozens of projects with Git. For applications we operate directly, GitHub Actions and Blacksmith build images for ECR and ECS. In client environments, we work with GitLab and CodeBuild pipelines targeting ECR, ECS and EKS. Many other tools connect to GitHub. The question is whether the gains would justify moving those connections.

The companies' official accounts describe different decisions. An internal monorepo, a developer's client and an automation service are different things to change. Sources were checked on October 14, 2026. Historical announcements describe their own period, and company performance figures are self-reported. This is not a benchmark of migrating our pipelines.

Companies changed different layers

Git is a version-control system. GitHub and GitLab provide review, permissions, status checks and integrations around it. Developers can change clients while retaining the server and pull requests. Replacing the storage format and server is a much larger migration.

Google built the centralized Piper system

Calling Google's internal system a modified Git would be inaccurate. Software Engineering at Google, written by Google engineers, describes Piper as an in-house centralized VCS for its shared internal monorepo. Large open-source projects such as Chromium and Android are exceptions.¹

That choice fits coordinated changes across products. The book's One Version policy shares one version of each dependency in the steady state, reducing divergent copies. A single repository still needs ownership and approval: Piper integrates path-level OWNERS into that process.¹

Google's contribution to Jujutsu (jj) is a separate matter. Its official repository identifies Google as a major contributor but says it is not a supported Google product.² That does not establish a company-wide replacement of Piper.

For us, the first question is how often shared code needs coordinated changes. When customer access and release schedules differ, we must weigh shared-dependency benefits against separate operating boundaries. That decision comes before building a server like Google's.

Meta evolved from Mercurial extensions to Sapling

Facebook's 2014 account explains its choice. It operated Subversion with a Git mirror, then evaluated growth. Splitting the codebase would complicate large atomic changes; extending Git's internals also looked difficult. It chose the more extensible Mercurial.³

The work targeted routine operations. Watchman identified changed files without rescanning everything. Remotefilelog fetched file contents when needed, reducing repeated history downloads across large clients.³

Sapling, introduced publicly in 2022, grew from that work into distinct storage formats, protocols and algorithms. It also changed the developer workflow: small changes can form individually reviewed stacks, with later changes restacked after an earlier edit. The public client supports Git repositories and GitHub.⁴

Monorepo operation required further design. Meta's 2025 account explains how branching the entire repository freezes unrelated projects. Directory branching copies a selected directory and tracks relationships so teams can manage versions, with build and search integration.⁵

Stacking small pull requests is something we can test. Installing the public client and adopting Meta's internal platform are different projects. Official documentation distinguishes .git and .sl modes and the availability of EdenFS and Mononoke capabilities.⁶ We should not expect internal-server performance merely by connecting a client to GitHub.

Anthropic designed Scion for online agents

Anthropic moved its internal monorepo from Git to Scion. Assuming online clients, its server handles commits, merges, rebases and history queries. Clients fetch needed files; query-only jobs use APIs without a working tree.⁷

That design can reduce repeated repository preparation. It also makes server availability and authorization central dependencies. Offline work, recovery and external integrations belong in the evaluation.

Anthropic also built Antique for review, plus search, authorization and CI. It excludes Scion as a general Git replacement and describes the migration burden.⁷ Our cost estimate must include those systems.

OpenAI's public examples automate pull-request operations

This research did not establish that OpenAI has abandoned Git. Its 2026 Symphony post describes CI monitoring, rebasing, conflict resolution and PR landing in its large internal monorepo. Issues receive dedicated workspaces and agents, while humans review results.⁸

There is also direct evidence from public repositories. The Agents SDK maintenance post describes GitHub Actions, AGENTS.md and repository-local skills.⁹ Neither source proves a single company-wide SCM. They do show that expanding agent-based development does not inherently require abandoning GitHub-centered workflows.

That approach is closer to our multi-project environment. We can test clearer task assignment, verification reports and review responses while retaining repositories and integrations. Defining what agents own and what counts as completion remains necessary.

Microsoft extended Git for Windows

Microsoft's 2017 GVFS announcement retained Git. The Windows codebase then contained more than 3.5 million files. GVFS exposed a complete-looking filesystem while downloading files on first access and reducing the scope Git needed to inspect.¹⁰

Microsoft addressed a large-repository problem by extending Git. When file counts slow status checks or working-tree preparation, materializing only needed files is one option to examine first. The 2017 tools and results are neither a description of every Microsoft team today nor a default recommendation for a new adoption.

Uber provided Git commands as a service

GitFarm, described by Uber in 2026, is not a replacement SCM. It retains upstream Git servers and executes other services' Git commands in isolated workspaces backed by prepared repositories. Clients avoid repeatedly preparing full clones for small reads or writes.¹¹

Not every automation task needs a build job. Identifying changed files or owners requires different data from compiling code. If reads repeat frequently, first separate tasks that the hosting platform's API can handle. Consider a shared execution service only where needed, including its authentication, isolation and repository freshness responsibilities.

Dropbox improved storage with GitHub

Dropbox reported reducing its server monorepo from 87GB to 20GB in 2026. Its internationalization paths interacted poorly with Git's compression heuristics. It worked with GitHub to tune server-side packing.¹²

The diagnosis is instructive. Dropbox examined storage and transfer behavior, not just code or large-file volume. Repacking locally and pushing does not change the server's transfer strategy, so the managed platform was part of the solution.¹² We cannot infer the same cause in our repositories. We can adopt the practice of narrowing the cause before replacing the tool.

What scale was Anthropic addressing?

Anthropic reported roughly 2,500 daily merges in May 2026, over 30,000 in September, and about 25 million daily CI checkouts.⁷ Per-copy cost multiplies at that volume.

We should examine repository count, individual size, change rate and the number of consumers. More agents do not increase all four at the same rate. Project count alone cannot justify a Scion-like design.

Server-side queries and fetching only needed files are useful principles. To apply them, first establish whether repository preparation is expensive and whether existing APIs or caches can reduce it. A company's reported savings are not our projected savings.

Dozens of projects differ from one enormous repository

A customer repository is both code storage and an access-and-delivery boundary. Separate approvals, secrets and release schedules can justify that separation. Sharing libraries and deployment templates is a separate decision from merging those boundaries.

Our paths are GitHub → GitHub Actions·Blacksmith → ECR·ECS and GitLab → CodeBuild → ECR·ECS·EKS. Start by identifying time spent on runner allocation, source preparation, dependency installation, image builds, tests and deployment stabilization.

If source preparation is brief but image builds are slow, a new SCM server leaves much of the wait intact. Faster checkouts do not remove review delays. Parallel stages should be assessed by the path that delays completion, not by summing their durations.

Our Blacksmith and GitHub Actions operating record covers execution layers and Docker caches. This article addresses the earlier decision about source control and its integrations.

Count the value of retaining GitHub integrations

Connected tools consume more than commits. They depend on PR numbers, approvals, check results and webhooks. AWS deployment permissions also depend on the execution environment. A custom SCM evaluation needs an inventory of how those contracts will continue.

GitHub Actions OIDC connects to AWS trust conditions. Moving the execution platform means reviewing its issuer and workload identity.¹³ Keeping ECR, ECS and EKS does not automatically preserve upstream authentication and approvals.

Permissions also need separate consideration when combining repositories. CODEOWNERS assigns review responsibility; repository roles define repository access.¹⁴¹⁵ Review ownership cannot substitute for a boundary that prevents one customer from reading another's code.

Choose improvements that can start small

The choices are broader than retaining Git unchanged or building a new server. Several changes can preserve the existing host.

If source preparation is the bottleneck, reduce downloaded data and materialized files. A shallow clone limits history depth; a partial clone limits objects downloaded. Sparse-checkout limits paths in the working tree.¹⁶¹⁷ These are different optimizations. Check the history required by version calculation, merge-base, bisect and related tools.

If maintaining project settings is expensive, standardize reusable CI and deployment contracts. Share common configuration while retaining customer-specific permissions and environments. Consistent management does not require one repository.

If stacking and revising small changes is awkward, test a Git-compatible tool such as Jujutsu or Sapling in one repository. Keeping the server and PRs limits the experiment. Compatibility does not mean feature equivalence: the Jujutsu documentation checked on the verification date lists restrictions for Git hooks, Git LFS and git-worktree; Sapling support also differs by mode.¹⁸⁶ Test the IDEs, agents, signatures, tags, submodules and checks you actually use.

If automation repeatedly reads the same data, examine whether APIs can answer the required questions without launching a whole build. Include the operating cost of any shared cache or execution service.

If the server remains a bottleneck after standard improvements, define the scope of a custom system. It needs owners for review, search, permissions and recovery, and a positive case after integration costs. Our measurements should justify that decision.

Decide using bottlenecks and total operating cost

The following is a proposed measurement sheet, not observed results. Select representative repositories and jobs, then compare the same commits, resource conditions and cache states. Record median and p95 durations, failures and retries.

Compare the same evaluation period:

Net migration value = avoidable spending + time value without double counting − migration and integration costs − additional operations, incident and training costs.

Reduced waiting time is not automatically cash saved. Multiplying asynchronous waits by everyone's salary overstates gains when other work can continue. Include caches, review and search, backups, incident response and AI tokens, not just servers. Choose a smaller change when the benefit disappears under conservative assumptions.

Define success before a pilot. Required tools must work, existing controls must hold, and bottlenecks and total costs must improve. Reduce the scope if the client bypasses checks or adds more operating work than it saves. Confirm how source, history and review records can continue under the previous approach.

Deployment completion still needs a definition in the AI era

Applying Anthropic's case to a smaller team raises the issue of code changing while checks run as agent changes increase. Verification results need an explicit link to the change and artifact tested. High merge volume alone does not justify removing a smaller team's pre-deployment checks.

GitHub merge queues have practical requirements. The plan and repository must qualify, and required CI must run on the merge_group event.¹⁹ A successful individual PR check can differ from a successful check of the actual merge combination.

Our deployment evidence should connect the commit, test results, ECR image digest and running version. CI success, ECS or EKS rollout and user-visible behavior are separate evidence states. Our article on ECS deployment completion signals explains that distinction in a deployment path.

The AI-DLC adoption and pilot guide covers the prerequisites for agent-based maintenance. More code makes it necessary to explain what was verified and what is complete.

Our current choice is to retain Git and its connections while measuring bottlenecks. Test compatible clients in a small scope; evaluate a custom server when existing limits and operating responsibility are established. The useful lessons from large tech companies are designs and decision criteria that fit our conditions.

Deciding where to change source control, builds or deployment requires examining the current workflow and costs together. 801Planet's Cloud & Infrastructure and AX Consulting support that assessment and staged execution.

References

These are official engineering sources and tool documentation. We did not independently reproduce the companies' operating results or measure the user's repository performance and costs in this research.