explained in the
"Non-cone Problems" section below, we do not recommend using it.
+
Use the `--[no-]sparse-index` option to use a sparse index (the
default is to not use it). A sparse index reduces the size of the
index to be more closely aligned with your sparse-checkout
definition. This can have significant performance advantages for
commands such as `git status` or `git add`. This feature is still
experimental. Some commands might be slower with a sparse index until
they are properly integrated with the feature.
+
**WARNING:** Using a sparse index requires modifying the index in a way
that is not completely understood by external tools. If you have trouble
with this compatibility, then run `git sparse-checkout init --no-sparse-index`
to rewrite your index to not be sparse. Older versions of Git will not
understand the sparse directory entries index extension and may fail to
interact with your repository until it is disabled.
'add'::
Update the sparse-checkout file to include additional directories
(in cone mode) or patterns (in non-cone mode). By default, these
directories or patterns are read from the command-line arguments,
but they can be read from stdin using the `--stdin` option.
'reapply'::
Reapply the sparsity pattern rules to paths in the working tree.
Commands like merge or rebase can materialize paths to do their
work (e.g. in order to show you a conflict), and other
sparse-checkout commands might fail to sparsify an individual file
(e.g. because it has unstaged changes or conflicts). In such
cases, it can make sense to run `git sparse-checkout reapply` later
after cleaning up affected paths (e.g. resolving conflicts, undoing
or committing changes, etc.).
+
The `reapply` command can also take `--[no-]cone` and `--[no-]sparse-index`
flags, with the same meaning as the flags from the `set` command, in order
to change which sparsity mode you are using without needing to also respecify
all sparsity paths.
'disable'::
Disable the `core.sparseCheckout` config setting, and restore the
working directory to include all files.
'init'::
Deprecated command that behaves like `set` with no specified paths.
May be removed in the future.
+
Historically, `set` did not handle all the necessary config settings,
which meant that both `init` and `set` had to be called. Invoking
both meant the `init` step would first remove nearly all tracked files
(and in cone mode, ignored files too), then the `set` step would add
many of the tracked files (but not ignored files) back. In addition
to the lost files, the performance and UI of this combination was
poor.
+
Also, historically, `init` would not actually initialize the
sparse-checkout file if it already existed. This meant it was
possible to return to a sparse-checkout without remembering which
paths to pass to a subsequent 'set' or 'add' command. However,
`--cone` and `--sparse-index` options would not be remembered across
the disable command, so the easy restore of calling a plain `init`
decreased in utility.
'check-rules'::
Check whether sparsity rules match one or more paths.
+
By default `check-rules` reads a list of paths from stdin and outputs only
the ones that match the current sparsity rules. The input is expected to consist
of one path per line, matching the output of `git ls-tree --name-only` including
that pathnames that begin with a double quote (") are interpreted as C-style
quoted strings.
+
When called with the `--rules-file <file>` flag the input files are matched
against the sparse checkout rules found in `<file>` instead of the current ones.
The rules in the files are expected to be in the same form as accepted by `git
sparse-checkout set --stdin` (in particular, they must be newline-delimited).
+
By default, the rules passed to the `--rules-file` option are interpreted as
cone mode directories. To pass non-cone mode patterns with `--rules-file`,
combine the option with the `--no-cone` option.
+
When called with the `-z` flag, the format of