only partially support it.

The update-index flags and the read-tree capabilities relating to the
skip-worktree bit predated the introduction of the
linkgit:git-sparse-checkout[1] command, which provides a much easier
way to configure and handle the skip-worktree bits.  If you want to
reduce your working tree to only deal with a subset of the files in
the repository, we strongly encourage the use of
linkgit:git-sparse-checkout[1] in preference to the low-level
update-index and read-tree primitives.

The primary purpose of the skip-worktree bit is to enable sparse
checkouts, i.e. to have working directories with only a subset of
paths present.  When the skip-worktree bit is set, Git commands (such
as `switch`, `pull`, `merge`) will avoid writing these files.
However, these commands will sometimes write these files anyway in
important cases such as conflicts during a merge or rebase.  Git
commands will also avoid treating the lack of such files as an
intentional deletion; for example `git add -u` will not stage a
deletion for these files and `git commit -a` will not make a commit
deleting them either.

Although this bit looks similar to assume-unchanged bit, its goal is
different.  The assume-unchanged bit is for leaving the file in the
working tree but having Git omit checking it for changes and presuming
that the file has not been changed (though if it can determine without
stat'ing the file that it has changed, it is free to record the
changes).  skip-worktree tells Git to ignore the absence of the file,
avoid updating it when possible with commands that normally update
much of the working directory (e.g. `checkout`, `switch`, `pull`,
etc.), and not have its absence be recorded in commits.  Note that in
sparse checkouts (setup by `git sparse-checkout` or by configuring
core.sparseCheckout to true), if a file is marked as skip-worktree in
the index but is found in the working tree, Git will clear the
skip-worktree bit for that file.

SPLIT INDEX
-----------

This mode is designed for repositories with very large indexes, and
aims at reducing the time it takes to repeatedly write these indexes.

In this mode, the index is split into two files, $GIT_DIR/index and
$GIT_DIR/sharedindex.<SHA-1>. Changes are accumulated in
$GIT_DIR/index, the split index, while the shared index file contains
all index entries and stays unchanged.

All changes in the split index are pushed back to the shared index
file when the number of entries in the split index reaches a level
specified by the splitIndex.maxPercentChange config variable (see
linkgit:git-config[1]).

Each time a new shared index file is created, the old shared index
files are deleted if their modification time is older than what is
specified by the splitIndex.sharedIndexExpire config variable (see
linkgit:git-config[1]).

To avoid deleting a shared index file that is still used, its
modification time is updated to the current time every time a new split
index based on the shared index file is either created or read from.

UNTRACKED CACHE
---------------

This cache is meant to speed up commands that involve determining
untracked files such as `git status`.

This feature works by recording the mtime of the working tree
directories and then omitting reading directories and stat calls
against files in those directories whose mtime hasn't changed. For
this to work the underlying operating system and file system must
change the `st_mtime` field of directories if files in the directory
are added, modified or deleted.

You can test whether the filesystem supports that with the
`--test-untracked-cache` option. The `--untracked-cache` option used
to implicitly perform that test in older versions of Git, but that's
no longer the case.

If you want to enable (or disable) this feature, it is easier to use
the `core.untrackedCache` configuration variable (see
linkgit:git-config[1]) than using the `--untracked-cache` option to
`git update-index` in each repository, especially if you want to do so