| 1 | git-sparse-checkout(1) |
| 2 | ====================== |
| 3 | |
| 4 | NAME |
| 5 | ---- |
| 6 | git-sparse-checkout - Reduce your working tree to a subset of tracked files |
| 7 | |
| 8 | |
| 9 | SYNOPSIS |
| 10 | -------- |
| 11 | [verse] |
| 12 | 'git sparse-checkout' (init | list | set | add | reapply | disable | check-rules | clean) [<options>] |
| 13 | |
| 14 | |
| 15 | DESCRIPTION |
| 16 | ----------- |
| 17 | |
| 18 | This command is used to create sparse checkouts, which change the |
| 19 | working tree from having all tracked files present to only having a |
| 20 | subset of those files. It can also switch which subset of files are |
| 21 | present, or undo and go back to having all tracked files present in |
| 22 | the working copy. |
| 23 | |
| 24 | The subset of files is chosen by providing a list of directories in |
| 25 | cone mode (the default), or by providing a list of patterns in |
| 26 | non-cone mode. |
| 27 | |
| 28 | When in a sparse-checkout, other Git commands behave a bit differently. |
| 29 | For example, switching branches will not update paths outside the |
| 30 | sparse-checkout directories/patterns, and `git commit -a` will not record |
| 31 | paths outside the sparse-checkout directories/patterns as deleted. |
| 32 | |
| 33 | THIS COMMAND IS EXPERIMENTAL. ITS BEHAVIOR, AND THE BEHAVIOR OF OTHER |
| 34 | COMMANDS IN THE PRESENCE OF SPARSE-CHECKOUTS, WILL LIKELY CHANGE IN |
| 35 | THE FUTURE. |
| 36 | |
| 37 | |
| 38 | COMMANDS |
| 39 | -------- |
| 40 | 'list':: |
| 41 | Describe the directories or patterns in the sparse-checkout file. |
| 42 | |
| 43 | 'set':: |
| 44 | Enable the necessary sparse-checkout config settings |
| 45 | (`core.sparseCheckout`, `core.sparseCheckoutCone`, and |
| 46 | `index.sparse`) if they are not already set to the desired values, |
| 47 | populate the sparse-checkout file from the list of arguments |
| 48 | following the 'set' subcommand, and update the working directory to |
| 49 | match. |
| 50 | + |
| 51 | To ensure that adjusting the sparse-checkout settings within a worktree |
| 52 | does not alter the sparse-checkout settings in other worktrees, the 'set' |
| 53 | subcommand will upgrade your repository config to use worktree-specific |
| 54 | config if not already present. The sparsity defined by the arguments to |
| 55 | the 'set' subcommand are stored in the worktree-specific sparse-checkout |
| 56 | file. See linkgit:git-worktree[1] and the documentation of |
| 57 | `extensions.worktreeConfig` in linkgit:git-config[1] for more details. |
| 58 | + |
| 59 | When the `--stdin` option is provided, the directories or patterns are |
| 60 | read from standard in as a newline-delimited list instead of from the |
| 61 | arguments. |
| 62 | + |
| 63 | By default, the input list is considered a list of directories, matching |
| 64 | the output of `git ls-tree -d --name-only`. This includes interpreting |
| 65 | pathnames that begin with a double quote (") as C-style quoted strings. |
| 66 | Note that all files under the specified directories (at any depth) will |
| 67 | be included in the sparse checkout, as well as files that are siblings |
| 68 | of either the given directory or any of its ancestors (see 'CONE PATTERN |
| 69 | SET' below for more details). In the past, this was not the default, |
| 70 | and `--cone` needed to be specified or `core.sparseCheckoutCone` needed |
| 71 | to be enabled. |
| 72 | + |
| 73 | When `--no-cone` is passed, the input list is considered a list of |
| 74 | patterns. This mode has a number of drawbacks, including not working |
| 75 | with some options like `--sparse-index`. As explained in the |
| 76 | "Non-cone Problems" section below, we do not recommend using it. |
| 77 | + |
| 78 | Use the `--[no-]sparse-index` option to use a sparse index (the |
| 79 | default is to not use it). A sparse index reduces the size of the |
| 80 | index to be more closely aligned with your sparse-checkout |
| 81 | definition. This can have significant performance advantages for |
| 82 | commands such as `git status` or `git add`. This feature is still |
| 83 | experimental. Some commands might be slower with a sparse index until |
| 84 | they are properly integrated with the feature. |
| 85 | + |
| 86 | **WARNING:** Using a sparse index requires modifying the index in a way |
| 87 | that is not completely understood by external tools. If you have trouble |
| 88 | with this compatibility, then run `git sparse-checkout init --no-sparse-index` |
| 89 | to rewrite your index to not be sparse. Older versions of Git will not |
| 90 | understand the sparse directory entries index extension and may fail to |
| 91 | interact with your repository until it is disabled. |
| 92 | |
| 93 | 'add':: |
| 94 | Update the sparse-checkout file to include additional directories |
| 95 | (in cone mode) or patterns (in non-cone mode). By default, these |
| 96 | directories or patterns are read from the command-line arguments, |
| 97 | but they can be read from stdin using the `--stdin` option. |
| 98 | |
| 99 | 'reapply':: |
| 100 | Reapply the sparsity pattern rules to paths in the working tree. |
| 101 | Commands like merge or rebase can materialize paths to do their |
| 102 | work (e.g. in order to show you a conflict), and other |
| 103 | sparse-checkout commands might fail to sparsify an individual file |
| 104 | (e.g. because it has unstaged changes or conflicts). In such |
| 105 | cases, it can make sense to run `git sparse-checkout reapply` later |
| 106 | after cleaning up affected paths (e.g. resolving conflicts, undoing |
| 107 | or committing changes, etc.). |
| 108 | + |
| 109 | The `reapply` command can also take `--[no-]cone` and `--[no-]sparse-index` |
| 110 | flags, with the same meaning as the flags from the `set` command, in order |
| 111 | to change which sparsity mode you are using without needing to also respecify |
| 112 | all sparsity paths. |
| 113 | |
| 114 | 'clean':: |
| 115 | Opportunistically remove files outside of the sparse-checkout |
| 116 | definition. This command requires cone mode to use recursive |
| 117 | directory matches to determine which files should be removed. A |
| 118 | file is considered for removal if it is contained within a tracked |
| 119 | directory that is outside of the sparse-checkout definition. |
| 120 | + |
| 121 | Some special cases, such as merge conflicts or modified files outside of |
| 122 | the sparse-checkout definition could lead to keeping files that would |
| 123 | otherwise be removed. Resolve conflicts, stage modifications, and use |
| 124 | `git sparse-checkout reapply` in conjunction with `git sparse-checkout |
| 125 | clean` to resolve these cases. |
| 126 | + |
| 127 | This command can be used to be sure the sparse index works efficiently, |
| 128 | though it does not require enabling the sparse index feature via the |
| 129 | `index.sparse=true` configuration. |
| 130 | + |
| 131 | To prevent accidental deletion of worktree files, the `clean` subcommand |
| 132 | will not delete any files without the `-f` or `--force` option, unless |
| 133 | the `clean.requireForce` config option is set to `false`. |
| 134 | + |
| 135 | The `--dry-run` option will list the directories that would be removed |
| 136 | without deleting them. Running in this mode can be helpful to predict the |
| 137 | behavior of the clean command or to determine which kinds of files are left |
| 138 | in the sparse directories. |
| 139 | + |
| 140 | The `--verbose` option will list every file within the directories that |
| 141 | are considered for removal. This option is helpful to determine if those |
| 142 | files are actually important or perhaps to explain why the directory is |
| 143 | still present despite the current sparse-checkout. |
| 144 | |
| 145 | 'disable':: |
| 146 | Disable the `core.sparseCheckout` config setting, and restore the |
| 147 | working directory to include all files. |
| 148 | |
| 149 | 'init':: |
| 150 | Deprecated command that behaves like `set` with no specified paths. |
| 151 | May be removed in the future. |
| 152 | + |
| 153 | Historically, `set` did not handle all the necessary config settings, |
| 154 | which meant that both `init` and `set` had to be called. Invoking |
| 155 | both meant the `init` step would first remove nearly all tracked files |
| 156 | (and in cone mode, ignored files too), then the `set` step would add |
| 157 | many of the tracked files (but not ignored files) back. In addition |
| 158 | to the lost files, the performance and UI of this combination was |
| 159 | poor. |
| 160 | + |
| 161 | Also, historically, `init` would not actually initialize the |
| 162 | sparse-checkout file if it already existed. This meant it was |
| 163 | possible to return to a sparse-checkout without remembering which |
| 164 | paths to pass to a subsequent 'set' or 'add' command. However, |
| 165 | `--cone` and `--sparse-index` options would not be remembered across |
| 166 | the disable command, so the easy restore of calling a plain `init` |
| 167 | decreased in utility. |
| 168 | |
| 169 | 'check-rules':: |
| 170 | Check whether sparsity rules match one or more paths. |
| 171 | + |
| 172 | By default `check-rules` reads a list of paths from stdin and outputs only |
| 173 | the ones that match the current sparsity rules. The input is expected to consist |
| 174 | of one path per line, matching the output of `git ls-tree --name-only` including |
| 175 | that pathnames that begin with a double quote (") are interpreted as C-style |
| 176 | quoted strings. |
| 177 | + |
| 178 | When called with the `--rules-file <file>` flag the input files are matched |
| 179 | against the sparse checkout rules found in `<file>` instead of the current ones. |
| 180 | The rules in the files are expected to be in the same form as accepted by `git |
| 181 | sparse-checkout set --stdin` (in particular, they must be newline-delimited). |
| 182 | + |
| 183 | By default, the rules passed to the `--rules-file` option are interpreted as |
| 184 | cone mode directories. To pass non-cone mode patterns with `--rules-file`, |
| 185 | combine the option with the `--no-cone` option. |
| 186 | + |
| 187 | When called with the `-z` flag, the format of the paths input on stdin as well |
| 188 | as the output paths are \0 terminated and not quoted. Note that this does not |
| 189 | apply to the format of the rules passed with the `--rules-file` option. |
| 190 | |
| 191 | |
| 192 | EXAMPLES |
| 193 | -------- |
| 194 | `git sparse-checkout set MY/DIR1 SUB/DIR2`:: |
| 195 | |
| 196 | Change to a sparse checkout with all files (at any depth) under |
| 197 | MY/DIR1/ and SUB/DIR2/ present in the working copy (plus all |
| 198 | files immediately under MY/ and SUB/ and the toplevel |
| 199 | directory). If already in a sparse checkout, change which files |
| 200 | are present in the working copy to this new selection. Note |
| 201 | that this command will also delete all ignored files in any |
| 202 | directory that no longer has either tracked or |
| 203 | non-ignored-untracked files present. |
| 204 | |
| 205 | `git sparse-checkout disable`:: |
| 206 | |
| 207 | Repopulate the working directory with all files, disabling sparse |
| 208 | checkouts. |
| 209 | |
| 210 | `git sparse-checkout add SOME/DIR/ECTORY`:: |
| 211 | |
| 212 | Add all files under SOME/DIR/ECTORY/ (at any depth) to the |
| 213 | sparse checkout, as well as all files immediately under |
| 214 | SOME/DIR/ and immediately under SOME/. Must already be in a |
| 215 | sparse checkout before using this command. |
| 216 | |
| 217 | `git sparse-checkout reapply`:: |
| 218 | |
| 219 | It is possible for commands to update the working tree in a |
| 220 | way that does not respect the selected sparsity directories. |
| 221 | This can come from tools external to Git writing files, or |
| 222 | even affect Git commands because of either special cases (such |
| 223 | as hitting conflicts when merging/rebasing), or because some |
| 224 | commands didn't fully support sparse checkouts (e.g. the old |
| 225 | `recursive` merge backend had only limited support). This |
| 226 | command reapplies the existing sparse directory specifications |
| 227 | to make the working directory match. |
| 228 | |
| 229 | INTERNALS -- SPARSE CHECKOUT |
| 230 | ---------------------------- |
| 231 | |
| 232 | "Sparse checkout" allows populating the working directory sparsely. It |
| 233 | uses the skip-worktree bit (see linkgit:git-update-index[1]) to tell Git |
| 234 | whether a file in the working directory is worth looking at. If the |
| 235 | skip-worktree bit is set, and the file is not present in the working tree, |
| 236 | then its absence is ignored. Git will avoid populating the contents of |
| 237 | those files, which makes a sparse checkout helpful when working in a |
| 238 | repository with many files, but only a few are important to the current |
| 239 | user. |
| 240 | |
| 241 | The `$GIT_DIR/info/sparse-checkout` file is used to define the |
| 242 | skip-worktree reference bitmap. When Git updates the working |
| 243 | directory, it updates the skip-worktree bits in the index based |
| 244 | on this file. The files matching the patterns in the file will |
| 245 | appear in the working directory, and the rest will not. |
| 246 | |
| 247 | INTERNALS -- NON-CONE PROBLEMS |
| 248 | ------------------------------ |
| 249 | |
| 250 | The `$GIT_DIR/info/sparse-checkout` file populated by the `set` and |
| 251 | `add` subcommands is defined to be a bunch of patterns (one per line) |
| 252 | using the same syntax as `.gitignore` files. In cone mode, these |
| 253 | patterns are restricted to matching directories (and users only ever |
| 254 | need supply or see directory names), while in non-cone mode any |
| 255 | gitignore-style pattern is permitted. Using the full gitignore-style |
| 256 | patterns in non-cone mode has a number of shortcomings: |
| 257 | |
| 258 | * Fundamentally, it makes various worktree-updating processes (pull, |
| 259 | merge, rebase, switch, reset, checkout, etc.) require O(N*M) pattern |
| 260 | matches, where N is the number of patterns and M is the number of |
| 261 | paths in the index. This scales poorly. |
| 262 | |
| 263 | * Avoiding the scaling issue has to be done via limiting the number |
| 264 | of patterns via specifying leading directory name or glob. |
| 265 | |
| 266 | * Passing globs on the command line is error-prone as users may |
| 267 | forget to quote the glob, causing the shell to expand it into all |
| 268 | matching files and pass them all individually along to |
| 269 | sparse-checkout set/add. While this could also be a problem with |
| 270 | e.g. "git grep -- *.c", mistakes with grep/log/status appear in |
| 271 | the immediate output. With sparse-checkout, the mistake gets |
| 272 | recorded at the time the sparse-checkout command is run and might |
| 273 | not be problematic until the user later switches branches or rebases |
| 274 | or merges, thus putting a delay between the user's error and when |
| 275 | they have a chance to catch/notice it. |
| 276 | |
| 277 | * Related to the previous item, sparse-checkout has an 'add' |
| 278 | subcommand but no 'remove' subcommand. Even if a 'remove' |
| 279 | subcommand were added, undoing an accidental unquoted glob runs |
| 280 | the risk of "removing too much", as it may remove entries that had |
| 281 | been included before the accidental add. |
| 282 | |
| 283 | * Non-cone mode uses gitignore-style patterns to select what to |
| 284 | *include* (with the exception of negated patterns), while |
| 285 | .gitignore files use gitignore-style patterns to select what to |
| 286 | *exclude* (with the exception of negated patterns). The |
| 287 | documentation on gitignore-style patterns usually does not talk in |
| 288 | terms of matching or non-matching, but on what the user wants to |
| 289 | "exclude". This can cause confusion for users trying to learn how |
| 290 | to specify sparse-checkout patterns to get their desired behavior. |
| 291 | |
| 292 | * Every other git subcommand that wants to provide "special path |
| 293 | pattern matching" of some sort uses pathspecs, but non-cone mode |
| 294 | for sparse-checkout uses gitignore patterns, which feels |
| 295 | inconsistent. |
| 296 | |
| 297 | * It has edge cases where the "right" behavior is unclear. Two examples: |
| 298 | + |
| 299 | First, two users are in a subdirectory, and the first runs |
| 300 | + |
| 301 | ---- |
| 302 | git sparse-checkout set '/toplevel-dir/*.c' |
| 303 | ---- |
| 304 | + |
| 305 | while the second runs |
| 306 | + |
| 307 | ---- |
| 308 | git sparse-checkout set relative-dir |
| 309 | ---- |
| 310 | + |
| 311 | Should those arguments be transliterated into |
| 312 | + |
| 313 | ---- |
| 314 | current/subdirectory/toplevel-dir/*.c |
| 315 | ---- |
| 316 | + |
| 317 | and |
| 318 | + |
| 319 | ---- |
| 320 | current/subdirectory/relative-dir |
| 321 | ---- |
| 322 | + |
| 323 | before inserting into the sparse-checkout file? The user who typed |
| 324 | the first command is probably aware that arguments to set/add are |
| 325 | supposed to be patterns in non-cone mode, and probably would not be |
| 326 | happy with such a transliteration. However, many gitignore-style |
| 327 | patterns are just paths, which might be what the user who typed the |
| 328 | second command was thinking, and they'd be upset if their argument |
| 329 | wasn't transliterated. |
| 330 | + |
| 331 | Second, what should bash-completion complete on for set/add commands |
| 332 | for non-cone users? If it suggests paths, is it exacerbating the |
| 333 | problem above? Also, if it suggests paths, what if the user has a |
| 334 | file or directory that begins with either a '!' or '#' or has a '*', |
| 335 | '\', '?', '[', or ']' in its name? And if it suggests paths, will |
| 336 | it complete "/pro" to "/proc" (in the root filesystem) rather than to |
| 337 | "/progress.txt" in the current directory? (Note that users are |
| 338 | likely to want to start paths with a leading '/' in non-cone mode, |
| 339 | for the same reason that .gitignore files often have one.) |
| 340 | Completing on files or directories might give nasty surprises in |
| 341 | all these cases. |
| 342 | |
| 343 | * The excessive flexibility made other extensions essentially |
| 344 | impractical. `--sparse-index` is likely impossible in non-cone |
| 345 | mode; even if it is somehow feasible, it would have been far more |
| 346 | work to implement and may have been too slow in practice. Some |
| 347 | ideas for adding coupling between partial clones and sparse |
| 348 | checkouts are only practical with a more restricted set of paths |
| 349 | as well. |
| 350 | |
| 351 | For all these reasons, non-cone mode is deprecated. Please switch to |
| 352 | using cone mode. |
| 353 | |
| 354 | |
| 355 | INTERNALS -- CONE MODE HANDLING |
| 356 | ------------------------------- |
| 357 | |
| 358 | The "cone mode", which is the default, lets you specify only what |
| 359 | directories to include. For any directory specified, all paths below |
| 360 | that directory will be included, and any paths immediately under |
| 361 | leading directories (including the toplevel directory) will also be |
| 362 | included. Thus, if you specified the directory |
| 363 | Documentation/technical/ |
| 364 | then your sparse checkout would contain: |
| 365 | |
| 366 | * all files in the toplevel-directory |
| 367 | * all files immediately under Documentation/ |
| 368 | * all files at any depth under Documentation/technical/ |
| 369 | |
| 370 | Also, in cone mode, even if no directories are specified, then the |
| 371 | files in the toplevel directory will be included. |
| 372 | |
| 373 | When changing the sparse-checkout patterns in cone mode, Git will inspect each |
| 374 | tracked directory that is not within the sparse-checkout cone to see if it |
| 375 | contains any untracked files. If all of those files are ignored due to the |
| 376 | `.gitignore` patterns, then the directory will be deleted. If any of the |
| 377 | untracked files within that directory is not ignored, then no deletions will |
| 378 | occur within that directory and a warning message will appear. If these files |
| 379 | are important, then reset your sparse-checkout definition so they are included, |
| 380 | use `git add` and `git commit` to store them, then remove any remaining files |
| 381 | manually to ensure Git can behave optimally. |
| 382 | |
| 383 | See also the "Internals -- Cone Pattern Set" section to learn how the |
| 384 | directories are transformed under the hood into a subset of the |
| 385 | Full Pattern Set of sparse-checkout. |
| 386 | |
| 387 | |
| 388 | INTERNALS -- FULL PATTERN SET |
| 389 | ----------------------------- |
| 390 | |
| 391 | The full pattern set allows for arbitrary pattern matches and complicated |
| 392 | inclusion/exclusion rules. These can result in O(N*M) pattern matches when |
| 393 | updating the index, where N is the number of patterns and M is the number |
| 394 | of paths in the index. To combat this performance issue, a more restricted |
| 395 | pattern set is allowed when `core.sparseCheckoutCone` is enabled. |
| 396 | |
| 397 | The sparse-checkout file uses the same syntax as `.gitignore` files; |
| 398 | see linkgit:gitignore[5] for details. Here, though, the patterns are |
| 399 | usually being used to select which files to include rather than which |
| 400 | files to exclude. (However, it can get a bit confusing since |
| 401 | gitignore-style patterns have negations defined by patterns which |
| 402 | begin with a '!', so you can also select files to _not_ include.) |
| 403 | |
| 404 | For example, to select everything, and then to remove the file |
| 405 | `unwanted` (so that every file will appear in your working tree except |
| 406 | the file named `unwanted`): |
| 407 | |
| 408 | git sparse-checkout set --no-cone '/*' '!unwanted' |
| 409 | |
| 410 | These patterns are just placed into the |
| 411 | `$GIT_DIR/info/sparse-checkout` as-is, so the contents of that file |
| 412 | at this point would be |
| 413 | |
| 414 | ---------------- |
| 415 | /* |
| 416 | !unwanted |
| 417 | ---------------- |
| 418 | |
| 419 | See also the "Sparse Checkout" section of linkgit:git-read-tree[1] to |
| 420 | learn more about the gitignore-style patterns used in sparse |
| 421 | checkouts. |
| 422 | |
| 423 | |
| 424 | INTERNALS -- CONE PATTERN SET |
| 425 | ----------------------------- |
| 426 | |
| 427 | In cone mode, only directories are accepted, but they are translated into |
| 428 | the same gitignore-style patterns used in the full pattern set. We refer |
| 429 | to the particular patterns used in those mode as being of one of two types: |
| 430 | |
| 431 | 1. *Recursive:* All paths inside a directory are included. |
| 432 | |
| 433 | 2. *Parent:* All files immediately inside a directory are included. |
| 434 | |
| 435 | Since cone mode always includes files at the toplevel, when running |
| 436 | `git sparse-checkout set` with no directories specified, the toplevel |
| 437 | directory is added as a parent pattern. At this point, the |
| 438 | sparse-checkout file contains the following patterns: |
| 439 | |
| 440 | ---------------- |
| 441 | /* |
| 442 | !/*/ |
| 443 | ---------------- |
| 444 | |
| 445 | This says "include everything immediately under the toplevel |
| 446 | directory, but nothing at any level below that." |
| 447 | |
| 448 | When in cone mode, the `git sparse-checkout set` subcommand takes a |
| 449 | list of directories. The command `git sparse-checkout set A/B/C` sets |
| 450 | the directory `A/B/C` as a recursive pattern, the directories `A` and |
| 451 | `A/B` are added as parent patterns. The resulting sparse-checkout file |
| 452 | is now |
| 453 | |
| 454 | ---------------- |
| 455 | /* |
| 456 | !/*/ |
| 457 | /A/ |
| 458 | !/A/*/ |
| 459 | /A/B/ |
| 460 | !/A/B/*/ |
| 461 | /A/B/C/ |
| 462 | ---------------- |
| 463 | |
| 464 | Here, order matters, so the negative patterns are overridden by the positive |
| 465 | patterns that appear lower in the file. |
| 466 | |
| 467 | Unless `core.sparseCheckoutCone` is explicitly set to `false`, Git will |
| 468 | parse the sparse-checkout file expecting patterns of these types. Git will |
| 469 | warn if the patterns do not match. If the patterns do match the expected |
| 470 | format, then Git will use faster hash-based algorithms to compute inclusion |
| 471 | in the sparse-checkout. If they do not match, git will behave as though |
| 472 | `core.sparseCheckoutCone` was false, regardless of its setting. |
| 473 | |
| 474 | In the cone mode case, despite the fact that full patterns are written |
| 475 | to the $GIT_DIR/info/sparse-checkout file, the `git sparse-checkout |
| 476 | list` subcommand will list the directories that define the recursive |
| 477 | patterns. For the example sparse-checkout file above, the output is as |
| 478 | follows: |
| 479 | |
| 480 | -------------------------- |
| 481 | $ git sparse-checkout list |
| 482 | A/B/C |
| 483 | -------------------------- |
| 484 | |
| 485 | If `core.ignoreCase=true`, then the pattern-matching algorithm will use a |
| 486 | case-insensitive check. This corrects for case mismatched filenames in the |
| 487 | 'git sparse-checkout set' command to reflect the expected cone in the working |
| 488 | directory. |
| 489 | |
| 490 | |
| 491 | INTERNALS -- SUBMODULES |
| 492 | ----------------------- |
| 493 | |
| 494 | If your repository contains one or more submodules, then submodules |
| 495 | are populated based on interactions with the `git submodule` command. |
| 496 | Specifically, `git submodule init -- <path>` will ensure the submodule |
| 497 | at `<path>` is present, while `git submodule deinit [-f] -- <path>` |
| 498 | will remove the files for the submodule at `<path>` (including any |
| 499 | untracked files, uncommitted changes, and unpushed history). Similar |
| 500 | to how sparse-checkout removes files from the working tree but still |
| 501 | leaves entries in the index, deinitialized submodules are removed from |
| 502 | the working directory but still have an entry in the index. |
| 503 | |
| 504 | Since submodules may have unpushed changes or untracked files, |
| 505 | removing them could result in data loss. Thus, changing sparse |
| 506 | inclusion/exclusion rules will not cause an already checked out |
| 507 | submodule to be removed from the working copy. Said another way, just |
| 508 | as `checkout` will not cause submodules to be automatically removed or |
| 509 | initialized even when switching between branches that remove or add |
| 510 | submodules, using `sparse-checkout` to reduce or expand the scope of |
| 511 | "interesting" files will not cause submodules to be automatically |
| 512 | deinitialized or initialized either. |
| 513 | |
| 514 | Further, the above facts mean that there are multiple reasons that |
| 515 | "tracked" files might not be present in the working copy: sparsity |
| 516 | pattern application from sparse-checkout, and submodule initialization |
| 517 | state. Thus, commands like `git grep` that work on tracked files in |
| 518 | the working copy may return results that are limited by either or both |
| 519 | of these restrictions. |
| 520 | |
| 521 | |
| 522 | SEE ALSO |
| 523 | -------- |
| 524 | |
| 525 | linkgit:git-read-tree[1] |
| 526 | linkgit:gitignore[5] |
| 527 | |
| 528 | GIT |
| 529 | --- |
| 530 | Part of the linkgit:git[1] suite |