Skip to main content
RunBook Academy

Git, CI/CD & GitOpsCII · Large Repository PerformanceSparse

Sparse-checkout and filter — only what you need

Intermediate⏱ ~22 mingit

What you'll learn

  • Use `git sparse-checkout init --cone` and `set` to restrict the working tree
  • Combine sparse-checkout with `--filter=blob:none` for working-tree and bandwidth savings
  • Recognise what sparse-checkout does not do (it does not restrict the audit trail or the CI build)
  • Verify a sparse-checkout with `git ls-files`

Prerequisites

Verified against Git 2.55.x teaching target; 2.40+ minimum · GitHub Actions continuous service; Aug 2026 documentation baseline · Argo CD v3.5.x teaching target; v3.0+ minimum · Flux v2.9.x · Sigstore Cosign v3.1.x · SLSA v1.2 · OCI Distribution Specification v1.1 · Git LFS v3.7.1 · Kubernetes (cross-course target) 1.36.x

Not yet marked complete on this device.

Sparse-checkout restricts the working tree to a subset of paths; filter restricts the packfile. Each is a performance optimisation, never an isolation mechanism. CODEOWNERS is the ownership mechanism.

The five sparse-checkout commands

git sparse-checkout init --cone
git sparse-checkout set "services/payments"
git sparse-checkout add "services/billing"
git sparse-checkout list
git sparse-checkout disable

init --cone enables cone mode (only one that scales). set replaces; add appends; list shows; disable removes.

flowchart LR
    A[packfile] -->|"sparse"| B[("subset tree")]
    A -->|"filter blob:none"| C[("defer blobs")]
    A -->|"sparse + filter"| D[("small + on-demand")]

The mechanisms are independent: sparse restricts the working tree; filter restricts the packfile.

Cone mode versus pattern mode

Cone mode (--cone) restricts by directory. Pattern mode allows globs but is O(history) per op and does not scale. Always use --cone; pattern mode is for backward compatibility only.

Combining with --filter

REPO_URL="https://github.com/example/monorepo.git"

git clone --filter=blob:none "$REPO_URL" repo
cd repo
git sparse-checkout init --cone
git sparse-checkout set "services/payments"
git ls-files | wc -l

The four commands: partial clone, init, set, verify. ls-files | wc -l should report a small count, not the full repo size.

Verification

git ls-files | wc -l
git sparse-checkout list

ls-files | wc -l should report a small count. list shows the allow-list; if empty, init was not run. A common failure is init without --cone, which succeeds but produces the unusable shape.

Production discipline

  1. Always --cone. Pattern mode does not scale.
  2. Verify with git ls-files | wc -l. A large count means the sparse-checkout is not active.
  3. Treat as performance, not isolation.
  4. Combine with --filter=blob:none for working trees.

Cross-course references

  • Linux for Production Sysadmins Part XXVI: bind-mounted subtrees.
  • Terraform for Production Sysadmins Part IX: workspace directories.

Quiz

Knowledge check · 4 questions

  1. Q1. An engineer runs `git sparse-checkout init` without `--cone`. What is the consequence?

  2. Q2. A sparse-checkout restricts the engineer's visibility of all directory contents.

  3. Q3. Name the four commands that combine partial clone with sparse-checkout, and identify the verification command that confirms the sparse-checkout is in effect.

  4. Q4. Verify whether the sparse-checkout is in effect, and recommend the next step if it is not.

    Engineer K owns `services/payments` in a 200 000-file monorepo. After setup, `git ls-files | wc -l` reports 199 800. IDE is slow.

Passing score: 75%. Answers are checked in this browser.