What does Git's sparse-checkout cone mode do, and how does it pair with a partial clone?

## The problem it solves A very large repository can have a working tree that is painful for reasons unrelated to network transfer: hundreds of thousands of files to write, `git status` scanning them all, editors and watchers indexing directories nobody on the team touches. Sparse checkout addresses the *working tree*, which is a separate axis from history depth and object transfer. ## The mechanism The index still lists every tracked path — Git's idea of the commit is unchanged. For paths outside the sparse selection, Git sets the `skip-worktree` bit on the index entry. That bit tells Git "do not expect this file on disk, and do not report it as deleted". Checkout writes only the selected paths; `git status` stays quiet about the rest. Because the index is complete, commits you create still contain the whole tree. Sparse checkout is not a way to remove files from history or from a commit; it only changes what is materialized locally. ## Cone mode versus pattern mode The original sparse-checkout accepted gitignore-style patterns in `.git/info/sparse-checkout`. That is expressive but slow: every path in the index must be tested against every pattern, and the rules are easy to get subtly wrong. **Cone mode** restricts you to directory paths. The selection becomes: all files in the repository root, plus every file under each named directory, plus the files in the parent directories leading to them. Because the rule is a directory-prefix decision, Git can evaluate it with a hash lookup per directory instead of a full pattern match, and it can skip entire subtrees at once. In recent Git, `git sparse-checkout set <dirs>` uses cone mode by default; `--no-cone` opts back into full pattern matching. The related commands are `git sparse-checkout list` (show the current selection), `add` (extend it), `reapply` (re-evaluate after the index or config changed) and `disable` (return to a full checkout). ## Pairing with partial clone Sparse checkout by itself still downloads everything: all commits, all trees, all blobs. If the goal is a smaller clone and not just a smaller working tree, pair it with a partial clone: `git clone --filter=blob:none --sparse <url>` transfers the graph without file contents, initializes a minimal sparse checkout at the repository root, and then fetches blobs only for the directories you actually select. That combination is what makes a huge repository workable on a laptop or in a path-scoped CI job. ## Where it bites - **Commands still see everything.** `git grep`, `git log -- <path>` and merges operate over the full tree; in a partial clone those may trigger lazy fetches for paths you never checked out. - **Merges and rebases touching excluded paths** are resolved from the index and objects, not from files on disk. That normally works, but a conflict in an excluded path is confusing because the file is not there to edit — Git will materialize it when it must. - **Tooling assumptions.** Build systems that glob the working tree see a partial repository and may conclude modules are missing. This is the most common source of "it works for me" reports. - **It is not access control.** Every excluded file is still in the object store or one fetch away; sparse checkout hides paths for convenience, never for confidentiality. ## When to reach for it Use it when engineers or CI jobs legitimately work on a bounded slice of a large tree and the checkout cost is measurable. Skip it when the repository is small enough that the full checkout is not a real cost — the added tooling confusion is not worth it.