NAME

git-update-index - Register file contents in the working tree to the index

SYNOPSIS

  1. git update-index
  2.          [--add] [--remove | --force-remove] [--replace]
  3.          [--refresh] [-q] [--unmerged] [--ignore-missing]
  4.          [(--cacheinfo <mode>,<object>,<file>)…​]
  5.          [--chmod=(+|-)x]
  6.          [--[no-]assume-unchanged]
  7.          [--[no-]skip-worktree]
  8.          [--[no-]fsmonitor-valid]
  9.          [--ignore-submodules]
  10.          [--[no-]split-index]
  11.          [--[no-|test-|force-]untracked-cache]
  12.          [--[no-]fsmonitor]
  13.          [--really-refresh] [--unresolve] [--again | -g]
  14.          [--info-only] [--index-info]
  15.          [-z] [--stdin] [--index-version <n>]
  16.          [--verbose]
  17.          [--] [<file>…​]

DESCRIPTION

Modifies the index or directory cache. Each file mentioned is updatedinto the index and any unmerged or needs updating state iscleared.

See also git-add[1] for a more user-friendly way to do some ofthe most common operations on the index.

The way git update-index handles files it is told about can be modifiedusing the various options:

OPTIONS

  • —add

  • If a specified file isn’t in the index already then it’sadded.Default behaviour is to ignore new files.

  • —remove

  • If a specified file is in the index but is missing then it’sremoved.Default behavior is to ignore removed file.

  • —refresh

  • Looks at the current index and checks to see if merges orupdates are needed by checking stat() information.

  • -q

  • Quiet. If —refresh finds that the index needs an update, the default behavior is to error out. This option makesgit update-index continue anyway.

  • —ignore-submodules

  • Do not try to update submodules. This option is only respectedwhen passed before —refresh.

  • —unmerged

  • If —refresh finds unmerged changes in the index, the defaultbehavior is to error out. This option makes git update-index continue anyway.

  • —ignore-missing

  • Ignores missing files during a —refresh

  • —cacheinfo ,,

  • —cacheinfo

  • Directly insert the specified info into the index. Forbackward compatibility, you can also give these threearguments as three separate parameters, but new users areencouraged to use a single-parameter form.

  • —index-info

  • Read index information from stdin.

  • —chmod=(+|-)x

  • Set the execute permissions on the updated files.

  • —[no-]assume-unchanged

  • When this flag is specified, the object names recordedfor the paths are not updated. Instead, this optionsets/unsets the "assume unchanged" bit for thepaths. When the "assume unchanged" bit is on, the userpromises not to change the file and allows Git to assumethat the working tree file matches what is recorded inthe index. If you want to change the working tree file,you need to unset the bit to tell Git. This issometimes helpful when working with a big project on afilesystem that has very slow lstat(2) system call(e.g. cifs).

    • Git will fail (gracefully) in case it needs to modify this filein the index e.g. when merging in a commit;thus, in case the assumed-untracked file is changed upstream,you will need to handle the situation manually.

    • —really-refresh

    • Like —refresh, but checks stat information unconditionally,without regard to the "assume unchanged" setting.

    • —[no-]skip-worktree

    • When one of these flags is specified, the object name recordedfor the paths are not updated. Instead, these optionsset and unset the "skip-worktree" bit for the paths. Seesection "Skip-worktree bit" below for more information.

    • —[no-]fsmonitor-valid

    • When one of these flags is specified, the object name recordedfor the paths are not updated. Instead, these optionsset and unset the "fsmonitor valid" bit for the paths. Seesection "File System Monitor" below for more information.

    • -g

    • —again

    • Runs git update-index itself on the paths whose indexentries are different from those from the HEAD commit.

    • —unresolve

    • Restores the unmerged or needs updating state of afile during a merge if it was cleared by accident.

    • —info-only

    • Do not create objects in the object database for all arguments that follow this flag; just inserttheir object IDs into the index.

    • —force-remove

    • Remove the file from the index even when the working directorystill has such a file. (Implies —remove.)

    • —replace

    • By default, when a file path exists in the index,git update-index refuses an attempt to add path/file.Similarly if a file path/file exists, a file pathcannot be added. With —replace flag, existing entriesthat conflict with the entry being added areautomatically removed with warning messages.

    • —stdin

    • Instead of taking list of paths from the command line,read list of paths from the standard input. Paths areseparated by LF (i.e. one path per line) by default.

    • —verbose

    • Report what is being added and removed from index.

    • —index-version

    • Write the resulting index out in the named on-disk format version.Supported versions are 2, 3 and 4. The current default version is 2or 3, depending on whether extra features are used, such asgit add -N.

    Version 4 performs a simple pathname compression that reduces indexsize by 30%-50% on large repositories, which results in faster loadtime. Version 4 is relatively young (first released in 1.8.0 inOctober 2012). Other Git implementations such as JGit and libgit2may not support it yet.

    • -z

    • Only meaningful with —stdin or —index-info; paths areseparated with NUL character instead of LF.

    • —split-index

    • —no-split-index
    • Enable or disable split index mode. If split-index mode isalready enabled and —split-index is given again, allchanges in $GIT_DIR/index are pushed back to the shared indexfile.

    These options take effect whatever the value of the core.splitIndexconfiguration variable (see git-config[1]). But a warning isemitted when the change goes against the configured value, as theconfigured value will take effect next time the index is read and thiswill remove the intended effect of the option.

    • —untracked-cache
    • —no-untracked-cache
    • Enable or disable untracked cache feature. Please use—test-untracked-cache before enabling it.

    These options take effect whatever the value of the core.untrackedCacheconfiguration variable (see git-config[1]). But a warning isemitted when the change goes against the configured value, as theconfigured value will take effect next time the index is read and thiswill remove the intended effect of the option.

    • —test-untracked-cache

    • Only perform tests on the working directory to make sureuntracked cache can be used. You have to manually enableuntracked cache using —untracked-cache or—force-untracked-cache or the core.untrackedCacheconfiguration variable afterwards if you really want to useit. If a test fails the exit code is 1 and a messageexplains what is not working as needed, otherwise the exitcode is 0 and OK is printed.

    • —force-untracked-cache

    • Same as —untracked-cache. Provided for backwardscompatibility with older versions of Git where—untracked-cache used to imply —test-untracked-cache butthis option would enable the extension unconditionally.

    • —fsmonitor

    • —no-fsmonitor

    • Enable or disable files system monitor feature. These optionstake effect whatever the value of the core.fsmonitorconfiguration variable (see git-config[1]). But a warningis emitted when the change goes against the configured value, asthe configured value will take effect next time the index isread and this will remove the intended effect of the option.

    • —

    • Do not interpret any more arguments as options.

    • Files to act on.Note that files beginning with . are discarded. This includes./file and dir/./file. If you don’t want this, then usecleaner names.The same applies to directories ending / and paths with //

USING —REFRESH

—refresh does not calculate a new sha1 file or bring the indexup to date for mode/content changes. But what it does do is to"re-match" the stat information of a file with the index, so that youcan refresh the index for a file that hasn’t been changed but wherethe stat entry is out of date.

For example, you’d want to do this after doing a git read-tree, to linkup the stat index details with the proper files.

USING —CACHEINFO OR —INFO-ONLY

—cacheinfo is used to register a file that is not in thecurrent working directory. This is useful for minimum-checkoutmerging.

To pretend you have a file at path with mode and sha1, say:

  1. $ git update-index --add --cacheinfo <mode>,<sha1>,<path>

—info-only is used to register files without placing them in the objectdatabase. This is useful for status-only repositories.

Both —cacheinfo and —info-only behave similarly: the index is updatedbut the object database isn’t. —cacheinfo is useful when the object isin the database but the file isn’t available locally. —info-only isuseful when the file is available, but you do not wish to update theobject database.

USING —INDEX-INFO

—index-info is a more powerful mechanism that lets you feedmultiple entry definitions from the standard input, and designedspecifically for scripts. It can take inputs of three formats:

  • mode SP type SP sha1 TAB path

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 theindex file and matches git ls-files —stage output.

  • mode SP sha1 TAB path

This format is no longer produced by any Git command, but isand will continue to be supported by update-index —index-info.

To place a higher stage entry to the index, the path shouldfirst be removed by feeding a mode=0 entry for the path, andthen feeding necessary input lines in the third format.

For example, starting with this index:

  1. $ git ls-files -s
  2. 100644 8a1218a1024a212bb3db30becd860315f9f3ac52 0       frotz

you can feed the following input to —index-info:

  1. $ git update-index --index-info
  2. 0 0000000000000000000000000000000000000000    frotz
  3. 100644 8a1218a1024a212bb3db30becd860315f9f3ac52 1    frotz
  4. 100755 8a1218a1024a212bb3db30becd860315f9f3ac52 2    frotz

The first line of the input feeds 0 as the mode to remove thepath; the SHA-1 does not matter as long as it is well formatted.Then the second and third line feeds stage 1 and stage 2 entriesfor that path. After the above, we would end up with this:

  1. $ git ls-files -s
  2. 100644 8a1218a1024a212bb3db30becd860315f9f3ac52 1    frotz
  3. 100755 8a1218a1024a212bb3db30becd860315f9f3ac52 2    frotz

USING “ASSUME UNCHANGED” BIT

Many operations in Git depend on your filesystem to have anefficient lstat(2) implementation, so that st_mtimeinformation for working tree files can be cheaply checked to seeif the file contents have changed from the version recorded inthe index file. Unfortunately, some filesystems haveinefficient lstat(2). If your filesystem is one of them, youcan set "assume unchanged" bit to paths you have not changed tocause Git not to do this check. Note that setting this bit on apath does not mean Git will check the contents of the file tosee if it has changed — it makes Git to omit any checking andassume it has not changed. When you make changes to workingtree files, you have to explicitly tell Git about it by dropping"assume unchanged" bit, either before or after you modify them.

In order to set "assume unchanged" bit, use —assume-unchangedoption. To unset, use —no-assume-unchanged. To see which fileshave the "assume unchanged" bit set, use git ls-files -v(see git-ls-files[1]).

The command looks at core.ignorestat configuration variable. Whenthis is true, paths updated with git update-index paths… andpaths updated with other Git commands that update both index andworking tree (e.g. git apply —index, git checkout-index -u,and git read-tree -u) are automatically marked as "assumeunchanged". Note that "assume unchanged" bit is not set ifgit update-index —refresh finds the working tree file matchesthe index (use git update-index —really-refresh if you wantto mark them as "assume unchanged").

EXAMPLES

To update and refresh only the files already checked out:

  1. $ git checkout-index -n -f -a && git update-index --ignore-missing --refresh
  • On an inefficient filesystem with core.ignorestat set 
  1. $ git update-index --really-refresh              (1)
  2. $ git update-index --no-assume-unchanged foo.c   (2)
  3. $ git diff --name-only                           (3)
  4. $ edit foo.c
  5. $ git diff --name-only                           (4)
  6. M foo.c
  7. $ git update-index foo.c                         (5)
  8. $ git diff --name-only                           (6)
  9. $ edit foo.c
  10. $ git diff --name-only                           (7)
  11. $ git update-index --no-assume-unchanged foo.c   (8)
  12. $ git diff --name-only                           (9)
  13. M foo.c

  • forces lstat(2) to set "assume unchanged" bits for paths that match index.

  • mark the path to be edited.

  • this does lstat(2) and finds index matches the path.

  • this does lstat(2) and finds index does not match the path.

  • registering the new version to index sets "assume unchanged" bit.

  • and it is assumed unchanged.

  • even after you edit it.

  • you can tell about the change after the fact.

  • now it checks with lstat(2) and finds it has been changed.

SKIP-WORKTREE BIT

Skip-worktree bit can be defined in one (long) sentence: When readingan entry, if it is marked as skip-worktree, then Git pretends itsworking directory version is up to date and read the index versioninstead.

To elaborate, "reading" means checking for file existence, readingfile attributes or file content. The working directory version may bepresent or absent. If present, its content may match against the indexversion or not. Writing is not affected by this bit, content safetyis still first priority. Note that Git can update working directoryfile, that is marked skip-worktree, if it is safe to do so (i.e.working directory version matches index version)

Although this bit looks similar to assume-unchanged bit, its goal isdifferent from assume-unchanged bit’s. Skip-worktree also takesprecedence over assume-unchanged bit when both are set.

SPLIT INDEX

This mode is designed for repositories with very large indexes, andaims 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 containsall index entries and stays unchanged.

All changes in the split index are pushed back to the shared indexfile when the number of entries in the split index reaches a levelspecified by the splitIndex.maxPercentChange config variable (seegit-config[1]).

Each time a new shared index file is created, the old shared indexfiles are deleted if their modification time is older than what isspecified by the splitIndex.sharedIndexExpire config variable (seegit-config[1]).

To avoid deleting a shared index file that is still used, itsmodification time is updated to the current time everytime a new splitindex based on the shared index file is either created or read from.

UNTRACKED CACHE

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

This feature works by recording the mtime of the working treedirectories and then omitting reading directories and stat callsagainst files in those directories whose mtime hasn’t changed. Forthis to work the underlying operating system and file system mustchange the st_mtime field of directories if files in the directoryare added, modified or deleted.

You can test whether the filesystem supports that with the—test-untracked-cache option. The —untracked-cache option usedto implicitly perform that test in older versions of Git, but that’sno longer the case.

If you want to enable (or disable) this feature, it is easier to usethe core.untrackedCache configuration variable (seegit-config[1]) than using the —untracked-cache option togit update-index in each repository, especially if you want to do soacross all repositories you use, because you can set the configurationvariable to true (or false) in your $HOME/.gitconfig just onceand have it affect all repositories you touch.

When the core.untrackedCache configuration variable is changed, theuntracked cache is added to or removed from the index the next time acommand reads the index; while when —[no-|force-]untracked-cacheare used, the untracked cache is immediately added to or removed fromthe index.

Before 2.17, the untracked cache had a bug where replacing a directorywith a symlink to another directory could cause it to incorrectly showfiles tracked by git as untracked. See the "status: add a failing testshowing a core.untrackedCache bug" commit to git.git. A workaround forthat is (and this might work for other undiscovered bugs in thefuture):

  1. $ git -c core.untrackedCache=false status

This bug has also been shown to affect non-symlink cases of replacinga directory with a file when it comes to the internal structures ofthe untracked cache, but no case has been reported where this resulted inwrong "git status" output.

There are also cases where existing indexes written by git versionsbefore 2.17 will reference directories that don’t exist anymore,potentially causing many "could not open directory" warnings to beprinted on "git status". These are new warnings for existing issuesthat were previously silently discarded.

As with the bug described above the solution is to one-off do a "gitstatus" run with core.untrackedCache=false to flush out the leftoverbad data.

FILE SYSTEM MONITOR

This feature is intended to speed up git operations for repos that havelarge working directories.

It enables git to work together with a file system monitor (see the"fsmonitor-watchman" section of githooks[5]) that caninform it as to what files have been modified. This enables git to avoidhaving to lstat() every file to find modified files.

When used in conjunction with the untracked cache, it can further improveperformance by avoiding the cost of scanning the entire working directorylooking for new files.

If you want to enable (or disable) this feature, it is easier to usethe core.fsmonitor configuration variable (seegit-config[1]) than using the —fsmonitor option togit update-index in each repository, especially if you want to do soacross all repositories you use, because you can set the configurationvariable in your $HOME/.gitconfig just once and have it affect allrepositories you touch.

When the core.fsmonitor configuration variable is changed, thefile system monitor is added to or removed from the index the next timea command reads the index. When —[no-]fsmonitor are used, the filesystem monitor is immediately added to or removed from the index.

CONFIGURATION

The command honors core.filemode configuration variable. Ifyour repository is on a filesystem whose executable bits areunreliable, this should be set to false (see git-config[1]).This causes the command to ignore differences in file modes recordedin the index and the file mode on the filesystem if they differ only onexecutable bit. On such an unfortunate filesystem, you mayneed to use git update-index —chmod=.

Quite similarly, if core.symlinks configuration variable is setto false (see git-config[1]), symbolic links are checked outas plain files, and this command does not modify a recorded file modefrom symbolic link to regular file.

The command looks at core.ignorestat configuration variable. SeeUsing "assume unchanged" bit section above.

The command also looks at core.trustctime configuration variable.It can be useful when the inode change time is regularly modified bysomething outside Git (file system crawlers and backup systems usectime for marking files processed) (see git-config[1]).

The untracked cache extension can be enabled by thecore.untrackedCache configuration variable (seegit-config[1]).

SEE ALSO

git-config[1],git-add[1],git-ls-files[1]

GIT

Part of the git[1] suite