Git Sparse Checkout and Submodules

directories `A` and `A/B` are added as parent patterns. The resulting sparse-checkout file is now ---------------- /* !/*/ /A/ !/A/*/ /A/B/ !/A/B/*/ /A/B/C/ ---------------- Here, order matters, so the negative patterns are overridden by the positive patterns that appear lower in the file. Unless `core.sparseCheckoutCone` is explicitly set to `false`, Git will parse the sparse-checkout file expecting patterns of these types. Git will warn if the patterns do not match. If the patterns do match the expected format, then Git will use faster hash-based algorithms to compute inclusion in the sparse-checkout. If they do not match, git will behave as though `core.sparseCheckoutCone` was false, regardless of its setting. In the cone mode case, despite the fact that full patterns are written to the $GIT_DIR/info/sparse-checkout file, the `git sparse-checkout list` subcommand will list the directories that define the recursive patterns. For the example sparse-checkout file above, the output is as follows: -------------------------- $ git sparse-checkout list A/B/C -------------------------- If `core.ignoreCase=true`, then the pattern-matching algorithm will use a case-insensitive check. This corrects for case mismatched filenames in the 'git sparse-checkout set' command to reflect the expected cone in the working directory. INTERNALS -- SUBMODULES ----------------------- If your repository contains one or more submodules, then submodules are populated based on interactions with the `git submodule` command. Specifically, `git submodule init -- <path>` will ensure the submodule at `<path>` is present, while `git submodule deinit [-f] -- <path>` will remove the files for the submodule at `<path>` (including any untracked files, uncommitted changes, and unpushed history). Similar to how sparse-checkout removes files from the working tree but still leaves entries in the index, deinitialized submodules are removed from the working directory but still have an entry in the index. Since submodules may have unpushed changes or untracked files, removing them could result in data loss. Thus, changing sparse inclusion/exclusion rules will not cause an already checked out submodule to be removed from the working copy. Said another way, just as `checkout` will not cause submodules to be automatically removed or initialized even when switching between branches that remove or add submodules, using `sparse-checkout` to reduce or expand the scope of "interesting" files will not cause submodules to be automatically deinitialized or initialized either. Further, the above facts mean that there are multiple reasons that "tracked" files might not be present in the working copy: sparsity pattern application from sparse-checkout, and submodule initialization state. Thus, commands like `git grep` that work on tracked files in the working copy may return results that are limited by either or both of these restrictions. SEE ALSO -------- linkgit:git-read-tree[1] linkgit:gitignore[5] GIT --- Part of the linkgit:git[1] suite

The `git sparse-checkout` command uses cone patterns to include or exclude files, with order mattering in the sparse-checkout file. Git will use faster algorithms if patterns match the expected format. Submodules are handled separately, and changing sparse inclusion/exclusion rules will not remove already checked out submodules. Tracked files may not be present in the working copy due to sparsity patterns or submodule initialization state, affecting commands like `git grep`.