Monorepo vs polyrepo at scale: what Google, Meta and Anthropic published

Only three companies have published first party numbers on running a single repository at extreme scale: Google, Meta and Anthropic. All three concluded that stock Git, used the way it was designed, would not carry their monorepo, and each built or adopted a server centric system instead. For everyone else, the choice between one repository and many is less about raw scale and more about security plumbing: how far one credential reaches, what each change costs to scan, how SBOMs are cut and who owns a vulnerability when it lands.

This post puts the published figures side by side, with the year attached to every number, then works through the security consequences with arithmetic you can check. For the shorter version, read our monorepo or separate repos security decision guide.

Key takeaways

• The public dataset is tiny. Google (2016 paper and its later engineering book), Meta (2014 and 2022 engineering posts plus the Sapling and Mononoke READMEs) and Anthropic (Scion post, October 2026) are the only primary, company published monorepo scale sources we could find. They span ten years and measure different things.
• The headline numbers. Google's book reports more than 80 TB in its Piper repository, about 50,000 engineers and 60,000 to 70,000 commits per workday. Anthropic reports a monorepo whose main branch history is almost 100 GB, around 30,000 merged changes per day in September 2026 (up from about 2,500 in May 2026) and about 25 million CI checkouts per day.
• Same conclusion, three times. Each company moved work to the server: Google with a centralized system, Meta with a Mercurial derived client and a Rust server, Anthropic with a server authoritative design that draws on Meta's Mononoke.
• Git has closed part of the gap. Partial clone, cone mode sparse checkout, Scalar and the planned reftable default for Git 3.0 target large repositories. None of them is an access control mechanism.
• Security cost scales with topology. At 30,000 merges a day, full repository scans on every change would cost roughly 40 times more compute than changed path scans under our stated assumptions. A single read credential in a monorepo reaches all code unless per directory permissions exist.

What Google, Meta and Anthropic actually published

We used only pages the companies published themselves and no secondary summaries; the method section explains the gaps.

Table 1: published monorepo scale figures, by company and year

Meta has not published a total size in bytes or a commits per day figure for its current monorepo, only orders of magnitude, so we kept its wording. Note also that the Anthropic figures are the most recent and the most granular, but they describe a single company over a single summer, during a period when Anthropic says its merge volume grew tenfold.

A useful sanity check on Anthropic's numbers: 600 PB divided by 25 million checkouts is 24 GB per checkout, which lines up with the "over 25 GB" compressed working copy the same post reports. The two figures are internally consistent, and that 24 GB is the cost Scion was designed to avoid paying on every CI job.

Why each company left stock Git, in its own words

Google. The Software Engineering at Google chapter on version control says the main repository runs on Piper, an in house centralized system, and that efforts to move to Git were blocked by the size of the codebase, the size of the user base and Hyrum's Law effects. The chapter puts it bluntly: "most existing tools don't scale well with 50,000 engineers." The 2016 paper frames the monorepo as "a common source of truth for tens of thousands of developers."

Meta. In January 2014, Facebook's engineers explained that they looked at Git first but judged "Git's internals would be difficult to work with" for an ambitious scaling project, and chose to extend Mercurial instead because it was modular Python with native code for hot paths. They added a file system monitor (Watchman) so status checks did not walk every file, and remotefilelog so clones fetched commit metadata and pulled file contents on demand. By the 2022 Sapling launch post, Meta said public source control systems "were not, and still are not" capable of handling a repository of its size, and that splitting the repository was ruled out because it would lose benefits such as simpler dependency management.

Anthropic. Anthropic's October 2026 post describes Git as a decentralized design where every clone is a complete, self contained repository. Anthropic was in practice running Git as a centralized system with one authoritative copy, and nearly all clients were agents and CI jobs that are always online. The post says the properties that make Git good for offline work were "actively undermining our ability to scale." It also says the cause of the merge growth was Claude's coding ability, and that coding is no longer the bottleneck for building systems.

Table 2: architecture choices compared (from each project's own documentation)

Anthropic credits both Google's Piper and Meta's Sapling as prior art, and says Mononoke "pioneered many of the techniques we use in Scion," especially its Bonsai data model. The Mononoke README itself does not mention Bonsai and describes the server as "still in development," so the lineage claim comes from Anthropic's post, not from Meta's.

A note on availability, because it matters for planning. Scion is internal to Anthropic and is not released; you cannot install it. Several community projects on public code hosts use the Scion name and state they are unaffiliated; they are not Anthropic's. Mononoke and EdenFS are open source but unsupported outside Meta. If your organization is not prepared to own a version control server, the realistic options are stock Git with its large repository features, or the Sapling client on top of a Git server.

What Git's own roadmap does for large repositories

Git has absorbed a lot of the ideas above, piece by piece. Here is what the official documentation says each feature does, and, just as important, what it does not do.

Partial clone

Partial clone lets a repository "better handle extremely large repositories" by downloading only some objects and fetching the rest on demand from a promisor remote. Filtered packfiles are marked with a .promisor file so Git can tell an intentionally missing object from a corrupt one. The documentation lists real limits: on demand fetching runs once per missing object, which adds overhead and can mean repeated authentication; it uses protocol v0 for that path, so each connection resends the full ref advertisement; and going offline requires prefetching.

Sparse checkout

Cone mode is now the default and non cone mode is deprecated. Sparse checkout uses the skip worktree bit so Git avoids populating files outside your patterns. The files are still tracked in the index. The documentation never presents it as a security boundary, and it is not one: anyone who can clone can run git sparse-checkout disable. We cover this in detail in sparse checkout is not access control.

Scalar

Scalar is Git's bundled tool for large repositories. By default scalar clone fetches only commit and tree objects, enables sparse checkout with only top level files present, registers background maintenance, and turns on the commit graph with changed path Bloom filters plus a multi pack index.

Reftable and the Git 3.0 breaking changes

The Git project's BreakingChanges page lists changes planned for Git 3.0, with no release date set:

• New repositories default to the reftable ref backend instead of files. The page notes that deleting refs with the files backend rewrites the whole packed-refs file, which can be dozens of megabytes in large repositories, and that multi ref writes are not atomic with files. Reftable fixes both.
• New repositories default to SHA-256 object names. SHA-1 is not planned for deprecation.
• safe.bareRepository changes from all to explicit, so Git refuses implicitly discovered bare repositories. That closes a class of tricks where a bare repository is embedded inside a larger working tree, which is more likely to go unnoticed in a huge monorepo.
• Rust becomes a build requirement, phased in from Git 2.52.

For the SHA-1 side of this story, see SHA-1 status and where it still shows up.

Table 3: stock Git features against the problems the three companies solved

The last row is the one security teams should care about most. Git has no notion of hiding a directory from a reader of the same repository. If a credential can fetch the repository, it can fetch every object reachable from the refs it can see.

The security trade-offs in numbers

Scale data is interesting. The decisions that follow from it are mostly about security and operations. We take the sub questions in turn.

Per change scanning cost: changed path scans versus full scans

Every merge into a protected branch should be scanned for new dependencies and new known vulnerabilities. The question is how much of the repository each scan touches.

Method. We used the published merge rates as inputs, then applied two stated assumptions:

1. A full dependency and SBOM scan of a very large monorepo costs 20 CPU minutes. That is an assumption for illustration, not a measured Safeguard figure. Real numbers vary by ecosystem, lockfile count and cache state.
2. A changed path scan, which rescans only the packages whose files or lockfiles changed plus their direct internal dependents, costs 0.5 CPU minutes on average.

Then CPU hours per day equals merges per day times CPU minutes per scan, divided by 60. "Cores busy around the clock" divides that by 24.

Table 4: computed scanning cost at published merge rates

Under these assumptions, changed path scanning is 40 times cheaper at every merge rate, because the ratio is just 20 divided by 0.5. The absolute numbers are what change the decision. At 2,500 merges a day, full scans on every merge are expensive but possible. At 30,000, they would need around 400 cores running all day just to keep up, before you count retries, queueing and the fact that merges cluster in working hours. Anthropic reports a 25% CPU capacity gain from CI alone after moving to Scion, which tells you how much of CI budget at that scale goes to moving bytes before any analysis begins.

Two cautions. Changed path scanning only works if you can compute the affected set correctly, which means a reliable map from paths to packages and from packages to their internal dependents. And it misses one class of change entirely: a new CVE published against a dependency nobody touched today. That is why changed path scans on merge should be paired with a scheduled full inventory, say nightly, and an on demand "who uses this component" query when an advisory drops. Our post on sharding scans of a large monorepo covers the mechanics.

Context: how big is a single company's merge rate next to a whole platform

GitHub's Octoverse 2025 report, covering September 2024 to August 2025, counts 43.2 million pull requests merged per month on average across the platform, about 518.7 million for the year. That averages about 1.42 million merges a day across 180 million plus developers and 630 million repositories. Anthropic's September 2026 figure of over 30,000 merges a day in one repository is roughly 2% of that platform wide daily average. The periods and units differ, so treat this as an order of magnitude comparison, not a share.

Access control: per directory in monorepos, per repository in polyrepos

In a polyrepo estate, the natural access boundary is the repository. A deploy key, a CI token or a contractor account that can read payments-service cannot read identity-service unless someone granted it. In a stock Git monorepo, the boundary is the whole repository. Everything that can clone can read everything.

Anthropic's post is explicit that Scion supports permissions on individual directories so sensitive code inside the monorepo can be protected, and that its review tool can express semantic approval constraints, for example telling a comment only change apart from a sensitive logic change. Google's book takes the other route for the cases that need it: it says separate repositories can make sense for projects with different secrecy, legal or security requirements, stitched back together as a virtual monorepo.

Table 5: blast radius of one leaked read credential

Write access is a separate question. In both topologies, write protection comes from protected branches and required reviews by code owners. The difference is granularity of review routing, which we cover under ownership below.

SBOMs: one per repository, one per package or one per deployable

A monorepo forces a decision that a polyrepo makes for you. With one repository per service, "one SBOM per repository" and "one SBOM per deployable" are usually the same thing. In a monorepo they are not, and a single SBOM for the whole tree is close to useless: it lists every dependency of every service, so a finding cannot be tied to what actually ships.

The practical pattern is one SBOM per deployable artifact, generated from the build of that artifact, with references between them. CycloneDX supports this through BOM-Link, a URN of the form urn:cdx:serialNumber/version#bom-ref that lets one BOM point at a component or another BOM without merging them. That keeps each SBOM separate, which also helps when different teams should only see their own. Our post one SBOM or many for a monorepo goes deeper.

Table 6: SBOM granularity options

Vulnerability ownership and routing

When a CVE lands in a shared dependency, someone has to own the fix. In a polyrepo estate the default owner is the repository's team, and the hard part is finding every repository that carries the vulnerable version. In a monorepo, finding the usages is easy, since everything is in one tree, but the fix may touch dozens of teams' directories in one change, so it has to be routed by path ownership.

Google's book describes about 1,000 teams in the monorepo with fewer than 10 using long lived development branches, and it argues that long lived dev branches "are not a good default plan." That is the operating model that makes one change across many owners feasible: everyone is on trunk, so one upgrade goes everywhere at once, and owners approve the parts they own. On the major Git hosting platforms the equivalent mechanism is a CODEOWNERS file plus required owner review on protected branches.

Dependency version drift: single version policy versus per repository pinning

Google's book states the One Version Rule plainly: developers "must never have a choice" of which version of a component to depend on. It admits the rule is not absolute; during third party upgrades, old and new versions may coexist briefly while usages migrate. The book also says Google's production jobs must be rebuilt and redeployed at least every six months, which caps how stale a running binary can be.

From a vulnerability standpoint, a single version policy has one big benefit and one big risk. The benefit: when you upgrade the shared version, every consumer gets the fix in one change. The risk: until you upgrade, every consumer is exposed together, and an upgrade with breaking changes can block the whole repository. Per repository pinning is the mirror image. Exposure is uneven, a fix in one repository fixes nothing elsewhere, and drift accumulates quietly. Meta's 2022 post names simplified dependency management as one of the reasons it never split its repository.

Table 7: version drift under each policy, by what happens on a critical CVE

Ranked: topology choice by organization size and merge rate

There is no published study that ranks topologies by outcome, so this ranking is ours. It combines the published scale data above with the security trade-offs in Tables 4 to 7. Rank 1 is the option we would try first for that row.

Table 8: ranked topology choices

Table 9: ranked published commit and merge rates (different metrics, read the note)

This ranking mixes commits with merged changes and design targets with measurements, and the figures are six years apart. It is a map of what has been disclosed, not a league table of who is biggest. Google's figure counts commits per workday, while Anthropic's counts merged code changes, and Anthropic's post attributes the growth to Claude's coding ability.

How we measured

• Sources. Only pages published by the company in question, plus official project documentation for Git, Sapling and CycloneDX. Facts about Anthropic come only from Anthropic's engineering post of 13 October 2026, updated 15 October 2026.
• Google 2016 paper. We fetched Google's research publication page for Potvin and Levenberg, "Why Google Stores Billions of Lines of Code in a Single Repository," Communications of the ACM, volume 59, 2016. The full text on the ACM site returned an access error to our fetcher, so we used only what the publication page states (authors, venue, year, "tens of thousands" of developers, "billions of lines of code"). The paper's detailed January 2015 snapshot figures are widely quoted elsewhere, but we did not reproduce any figure we could not read on a primary page. For quantitative Google figures we used chapter 16 of Software Engineering at Google, which Google hosts on abseil.io.
• Years. Each figure carries the year of the publication or the period the source names. The book does not print its publication year on the chapter page; it was published in 2020.
• Computed figures. Table 4 uses the published merge rates and two assumptions we state explicitly (20 CPU minutes per full scan, 0.5 per changed path scan). The Octoverse comparison divides 43.2 million monthly merged pull requests by 30.4 days. The 24 GB per checkout check divides Anthropic's 600 PB by 25 million.
• Not like for like. Commits, merged changes and design targets are different metrics. We label each one and never sum or average across companies.
• Ranked topology table. This is editorial judgment from the data, not a survey result.

Step by step: make a stock Git monorepo behave at scale, with security in the loop

The commands below use only documented Git features plus the Safeguard CLI. Adjust paths for your layout.

1. Clone without pulling all history and all files

# Option A: Git's bundled large repo tool
scalar clone https://git.example.com/org/monorepo.git
cd monorepo/src
git sparse-checkout set services/payments libs/crypto

# Option B: plain Git with a blobless partial clone and cone mode sparse checkout
git clone --filter=blob:none --sparse https://git.example.com/org/monorepo.git
cd monorepo
git sparse-checkout set services/payments libs/crypto
git sparse-checkout list

Remember that this limits what is on disk, not what the credential can read.

2. Opt new repositories into reftable ahead of Git 3.0

git config --global init.defaultRefFormat reftable
git config --global init.defaultBranch main
# Refuse implicitly discovered bare repositories now, before 3.0 makes it the default
git config --global safe.bareRepository explicit

Check that every tool that touches the repository (CI runners, alternative Git libraries, code search) supports reftable before converting an existing repository.

3. Turn on background maintenance

git maintenance start

Scalar does this for you. Without it, packfiles and the commit graph degrade as the repository grows.

4. Declare ownership by path

A CODEOWNERS file at the repository root routes review to owners, and with required owner review on the protected branch, routes security fixes too:

/services/payments/   @org/payments-team
/services/identity/   @org/identity-team
/libs/crypto/         @org/security-eng
/third_party/         @org/platform-deps

5. Compute the affected set for each change

# Files changed by this pull request
git diff --name-only origin/main...HEAD > changed.txt

# Map paths to package roots (example for a services and libs layout)
awk -F/ '{print $1"/"$2}' changed.txt | sort -u > packages.txt
cat packages.txt

For accurate results you also need internal dependents of changed libraries. Your build system's query tool is the right source for that graph.

6. Scan only the affected packages on merge, and everything on a schedule

name: dependency-scan
on:
  pull_request:
    paths:
      - "services/**"
      - "libs/**"
  schedule:
    - cron: "0 2 * * *"
jobs:
  changed:
    if: github.event_name == 'pull_request'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
          filter: blob:none
      - run: npm install -g @safeguard-sh/cli
      - run: |
          git diff --name-only origin/${{ github.base_ref }}...HEAD \
            | awk -F/ '{print $1"/"$2}' | sort -u > packages.txt
          while read -r pkg; do
            [ -d "$pkg" ] && safeguard scan --dir "$pkg"
          done < packages.txt
  full:
    if: github.event_name == 'schedule'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm install -g @safeguard-sh/cli
      - run: safeguard scan --dir .

Results land as JSON under ./output. Running the scan once per deployable directory gives you one SBOM per deployable, which is the granularity Table 6 recommends.

7. Split out what needs a read boundary

If a directory needs to be invisible to most of the company, stock Git cannot do that inside one repository. Move it to its own repository and consume it as a versioned artifact. Our guide to importing repositories into a monorepo with git filter-repo covers the reverse direction, and the same tool works for extracting a directory with its history.

Where Safeguard fits

Safeguard does not replace your version control system and does not provide per directory read permissions inside a Git repository. That boundary has to come from your hosting layer or from splitting repositories.

What it does today, generally available:

• SBOM and dependency scanning of a directory, a container image or an SBOM file (safeguard scan --dir <path>, --image <name>, --sbom <file>), in SPDX and CycloneDX. Pointing it at each deployable directory gives per deployable SBOMs in a monorepo.
• Component inventory across projects, so when an advisory lands you can see which projects carry a given component and version. That is the polyrepo pain point in Table 7.
• Vulnerability matching and reachability analysis, so a monorepo with thousands of transitive dependencies does not drown owners in findings for code paths nobody calls.
• Policies and gates evaluated in the platform and in CI, so a vulnerable version removed today does not return on tomorrow's merge.
• Autonomous remediation that opens tested fix pull requests, singly or in bulk. Bulk mode opens one pull request per repository, so in a monorepo a shared upgrade arrives as one change for path owners to review, and in a polyrepo estate it arrives as one change per affected repository. It ships switched off.

For the incident response side of inventory, see SBOM incident response: finding affected products fast.

Common mistakes

• Copying Google's topology without Google's tooling. The three companies that published monorepo data all built or adopted custom servers. A stock Git monorepo can work very well, but not with stock Git defaults past a few thousand merges a day.
• Treating sparse checkout as access control. It controls what is on disk. The credential still reads everything.
• One SBOM for the whole monorepo. It lists every service's dependencies, so nobody can say what shipped.
• Changed path scanning with no nightly full scan. New CVEs against untouched dependencies are invisible until someone edits the package.
• Computing the affected set from paths alone. A change to a shared library affects every internal dependent, even if their paths did not change.
• Single version policy with no escape hatch. A breaking upgrade of a vulnerable library can freeze the whole repository. Google's book notes that old and new versions sometimes coexist briefly during migrations; plan for that.
• Per repository pinning with no central inventory. Drift accumulates silently, and the fix you merged in one repository protects none of the others.

FAQ

Is a monorepo more secure than a polyrepo?

Neither is more secure by default. A monorepo makes inventory and single change upgrades easier but widens the reach of a read credential. A polyrepo narrows read access per repository but makes it harder to find and fix every copy of a vulnerable dependency. Pick based on which of those problems you are better staffed to solve.

How big is Google's monorepo?

Google's Software Engineering at Google (2020) says Piper stores more than 80 TB of content and metadata, with about 50,000 engineers and 60,000 to 70,000 commits per workday. The 2016 CACM paper describes billions of lines of code shared by tens of thousands of developers.

How big is Anthropic's monorepo?

Anthropic's October 2026 post says the main branch history is almost 100 GB, the compressed working copy is over 25 GB, CI runs about 25 million checkouts per day, and merged changes rose from about 2,500 a day in May 2026 to over 30,000 a day in September 2026.

Can I use Scion?

No. Scion is internal to Anthropic. Anthropic says it is not a suitable replacement for Git for general use and that it hopes to bring some ideas to Git with the major hosting platforms and the open source community. Projects online that use the name and say they are unaffiliated are not Anthropic's.

Can Git handle a very large monorepo?

Git handles large repositories much better than it did a decade ago thanks to partial clone, sparse checkout, Scalar, background maintenance and the reftable backend. The published operators at the very top of the scale still built server centric systems, mainly to avoid moving full history to every client.

Does sparse checkout restrict who can see code?

No. Sparse checkout controls which files Git writes to your working tree. Anyone who can clone the repository can disable it and read everything.

How many SBOMs should a monorepo have?

One per deployable artifact, linked to each other, plus a scheduled full inventory. A single SBOM for the whole tree cannot tell you what actually shipped.

What is the One Version Rule?

It is Google's policy, described in its engineering book, that developers should never choose between versions of the same dependency. It makes fleet wide upgrades a single change and is easiest to enforce in a monorepo.

Should a fast growing, agent heavy team choose a monorepo?

Anthropic's own data shows merge volume can grow more than tenfold in a few months when agents write code. Start with a stock Git monorepo using the large repository features, scan changed paths on merge with a nightly full scan, and split out anything that needs a read boundary early, before the history makes it painful.

Fix it without waiting for upstream

Whatever your topology, the same shared dependency usually turns up in dozens of packages or repositories at once, so the gap between a fix existing and a fix running in every deployable is where most of the exposure sits.

In incidents like this one, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

To try the flows below on your own repository, download Safeguard and read the CLI docs.

The first demo is a real Safeguard CLI session. You ask it to fix the lodash CVE in a repository; it reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing. In a monorepo you would run the same flow inside one package directory, so the change stays inside a single owner's path.

Click through it at your own pace, or open it full screen.

The second demo sets up the runner on your own machine, approves it with its device code and scans from the terminal. For a large monorepo this keeps scanning next to the checkout, which matters when a full clone is tens of gigabytes and you only want to scan the packages that changed.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. For agent heavy teams, the kind whose merge rates Anthropic's data describes, this is how an agent can ask which projects carry a vulnerable component before it opens a change.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• Anthropic Engineering: Redesigning source control at Anthropic (13 Oct 2026, updated 15 Oct 2026)
• Google Research: Why Google Stores Billions of Lines of Code in a Single Repository (CACM, 2016)
• Software Engineering at Google, chapter 16: Version Control and Branch Management
• Meta Engineering: Scaling Mercurial at Facebook (7 Jan 2014)
• Meta Engineering: Sapling, source control that's user friendly and scalable (15 Nov 2022)
• Sapling repository README
• Mononoke README
• Git documentation: partial clone
• Git documentation: git sparse-checkout
• Git documentation: scalar
• Git documentation: BreakingChanges (Git 3.0)
• GitHub Octoverse 2025
• CycloneDX: BOM-Link

Last reviewed: 23 October 2026. Figures are as published by each company on the dates shown; check the linked pages for updates.