[--chmod=(+|-)x]
[--[no-]assume-unchanged]
[--[no-]skip-worktree]
+ [--[no-]fsmonitor-valid]
[--ignore-submodules]
[--[no-]split-index]
[--[no-|test-|force-]untracked-cache]
+ [--[no-]fsmonitor]
[--really-refresh] [--unresolve] [--again | -g]
[--info-only] [--index-info]
[-z] [--stdin] [--index-version <n>]
set and unset the "skip-worktree" bit for the paths. See
section "Skip-worktree bit" below for more information.
+--[no-]fsmonitor-valid::
+ When one of these flags is specified, the object name recorded
+ for the paths are not updated. Instead, these options
+ set and unset the "fsmonitor valid" bit for the paths. See
+ section "File System Monitor" below for more information.
+
-g::
--again::
Runs 'git update-index' itself on the paths whose index
`--untracked-cache` used to imply `--test-untracked-cache` but
this option would enable the extension unconditionally.
+--fsmonitor::
+--no-fsmonitor::
+ Enable or disable files system monitor feature. These options
+ take effect whatever the value of the `core.fsmonitor`
+ configuration variable (see linkgit:git-config[1]). But a warning
+ is emitted when the change goes against the configured value, as
+ the configured value will take effect next time the index is
+ read and this will remove the intended effect of the option.
+
\--::
Do not interpret any more arguments as options.
cleaner names.
The same applies to directories ending '/' and paths with '//'
-Using --refresh
+USING --REFRESH
---------------
`--refresh` does not calculate a new sha1 file or bring the index
up to date for mode/content changes. But what it *does* do is to
For example, you'd want to do this after doing a 'git read-tree', to link
up the stat index details with the proper files.
-Using --cacheinfo or --info-only
+USING --CACHEINFO OR --INFO-ONLY
--------------------------------
`--cacheinfo` is used to register a file that is not in the
current working directory. This is useful for minimum-checkout
merging.
-To pretend you have a file with mode and sha1 at path, say:
+To pretend you have a file at path with mode and sha1, say:
----------------
-$ git update-index --cacheinfo <mode>,<sha1>,<path>
+$ git update-index --
add --cacheinfo <mode>,<sha1>,<path>
----------------
`--info-only` is used to register files without placing them in the object
object database.
-Using --index-info
+USING --INDEX-INFO
------------------
`--index-info` is a more powerful mechanism that lets you feed
multiple entry definitions from the standard input, and designed
specifically for scripts. It can take inputs of three formats:
- . mode SP sha1 TAB path
-+
-The first format is what "git-apply --index-info"
-reports, and used to reconstruct a partial tree
-that is used for phony merge base tree when falling
-back on 3-way merge.
-
. mode SP type SP sha1 TAB path
+
-The second format is to stuff 'git ls-tree' output
-into the index file.
+This format is to stuff `git ls-tree` output into the index.
. mode SP sha1 SP stage TAB path
+
This format is to put higher order stages into the
index file and matches 'git ls-files --stage' output.
+ . mode SP sha1 TAB path
++
+This format is no longer produced by any Git command, but is
+and will continue to be supported by `update-index --index-info`.
+
To place a higher stage entry to the index, the path should
first be removed by feeding a mode=0 entry for the path, and
then feeding necessary input lines in the third format.
------------
-Using ``assume unchanged'' bit
+USING ``ASSUME UNCHANGED'' BIT
------------------------------
Many operations in Git depend on your filesystem to have an
to mark them as "assume unchanged").
-Examples
+EXAMPLES
--------
To update and refresh only the files already checked out:
<9> now it checks with lstat(2) and finds it has been changed.
-Skip-worktree bit
+SKIP-WORKTREE BIT
-----------------
Skip-worktree bit can be defined in one (long) sentence: When reading
different from assume-unchanged bit's. Skip-worktree also takes
precedence over assume-unchanged bit when both are set.
-Split index
+SPLIT INDEX
-----------
This mode is designed for repositories with very large indexes, and
modification time is updated to the current time everytime a new split
index based on the shared index file is either created or read from.
-Untracked cache
+UNTRACKED CACHE
---------------
This cache is meant to speed up commands that involve determining
are used, the untracked cache is immediately added to or removed from
the index.
-Configuration
+Before 2.17, the untracked cache had a bug where replacing a directory
+with a symlink to another directory could cause it to incorrectly show
+files tracked by git as untracked. See the "status: add a failing test
+showing a core.untrackedCache bug" commit to git.git. A workaround for
+that is (and this might work for other undiscovered bugs in the
+future):
+
+----------------
+$ git -c core.untrackedCache=false status
+----------------
+
+This bug has also been shown to affect non-symlink cases of replacing
+a directory with a file when it comes to the internal structures of
+the untracked cache, but no case has been reported where this resulted in
+wrong "git status" output.
+
+There are also cases where existing indexes written by git versions
+before 2.17 will reference directories that don't exist anymore,
+potentially causing many "could not open directory" warnings to be
+printed on "git status". These are new warnings for existing issues
+that were previously silently discarded.
+
+As with the bug described above the solution is to one-off do a "git
+status" run with `core.untrackedCache=false` to flush out the leftover
+bad data.
+
+FILE SYSTEM MONITOR
+-------------------
+
+This feature is intended to speed up git operations for repos that have
+large working directories.
+
+It enables git to work together with a file system monitor (see the
+"fsmonitor-watchman" section of linkgit:githooks[5]) that can
+inform it as to what files have been modified. This enables git to avoid
+having to lstat() every file to find modified files.
+
+When used in conjunction with the untracked cache, it can further improve
+performance by avoiding the cost of scanning the entire working directory
+looking for new files.
+
+If you want to enable (or disable) this feature, it is easier to use
+the `core.fsmonitor` configuration variable (see
+linkgit:git-config[1]) than using the `--fsmonitor` option to
+`git update-index` in each repository, especially if you want to do so
+across all repositories you use, because you can set the configuration
+variable in your `$HOME/.gitconfig` just once and have it affect all
+repositories you touch.
+
+When the `core.fsmonitor` configuration variable is changed, the
+file system monitor is added to or removed from the index the next time
+a command reads the index. When `--[no-]fsmonitor` are used, the file
+system monitor is immediately added to or removed from the index.
+
+CONFIGURATION
-------------
The command honors `core.filemode` configuration variable. If