Git, CI/CD & GitOpsCII · Large Repository PerformanceSparse
Sparse-checkout and filter — only what you need
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
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
- Always
--cone. Pattern mode does not scale. - Verify with
git ls-files | wc -l. A large count means the sparse-checkout is not active. - Treat as performance, not isolation.
- Combine with
--filter=blob:nonefor 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
Q1. An engineer runs `git sparse-checkout init` without `--cone`. What is the consequence?
Q2. A sparse-checkout restricts the engineer's visibility of all directory contents.
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.
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.