Performance on big repositories

Monorepos with millions of files or long histories become unusable without these features.

Big repositories are slow for different reasons, and each has a remedy.

Too much history or too many blobs to download:

Partial clone git clone --filter=blob:none <url> downloads all commits and trees but fetches file contents lazily, on demand. History commands still work. This is usually the best choice for developers.
--filter=tree:0 goes further (fetches trees lazily too); suited to one-off CI builds.
Shallow clone --depth=1 truncates history entirely. Fast for CI, but log, blame and merges with old branches suffer; git fetch --unshallow repairs it.

Too many files in the working tree:

Sparse checkout git sparse-checkout set --cone services/api libs/common checks out only the directories you need; with cone mode and a sparse index, index operations scale with what you checked out.

Slow status, log and graph commands:

core.fsmonitor true uses the built-in filesystem monitor daemon (macOS, Windows) so git status doesn't scan every file; core.untrackedCache true caches untracked-file scans.
The commit-graph file speeds up log, merge-base and reachability queries; fetch.writeCommitGraph true keeps it current.

Keeping it all tuned: git maintenance start registers the repository for background tasks (prefetch, commit-graph, loose-object packing, incremental repack) through the OS scheduler, so you never need a blocking gc.

`scalar` (shipped with Git) bundles these: scalar clone <url> sets up partial clone, sparse checkout, fsmonitor and maintenance in one command.

Large binary assets are a separate problem: use Git LFS so they live outside the object store.

Example

# Developer clone of a big monorepo
git clone --filter=blob:none --sparse git@github.com:acme/mono.git
cd mono
git sparse-checkout set --cone services/api libs/common
git config core.fsmonitor true
git config core.untrackedCache true
git maintenance start          # background prefetch, commit-graph, repack

# CI: fastest possible checkout of one commit
git clone --depth=1 --filter=blob:none https://github.com/acme/mono.git

# Or all of the above in one go
scalar clone https://github.com/acme/mono.git

Remember

Partial clone (--filter=blob:none) fetches file contents on demand
Shallow clones are for CI; they cripple history commands
Sparse checkout + sparse index shrink the working tree and index
fsmonitor, commit-graph and git maintenance keep daily commands fast

Watch out for

Using --depth=1 clones for daily development and then fighting broken merges and missing history.

Check yourself

Which clone keeps full commit history but downloads file contents only when needed?
What does git maintenance start do?

Official docs: git-scm.com/docs/git-maintenance

Example

Remember

Watch out for

Check yourself

Builds on

Unlocks