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


   git update-index
                [--add] [--remove | --force-remove] [--replace]
                [--refresh] [-q] [--unmerged] [--ignore-missing]
                [(--cacheinfo <mode>,<object>,<file>)...]
                [--really-refresh] [--unresolve] [--again | -g]
                [--info-only] [--index-info]
                [-z] [--stdin] [--index-version <n>]
                [--] [<file>...]


   Modifies the index or directory cache. Each file mentioned is updated
   into the index and any unmerged or needs updating state is cleared.

   See also git-add(1) for a more user-friendly way to do some of the most
   common operations on the index.

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


       If a specified file isn't in the index already then it's added.
       Default behaviour is to ignore new files.

       If a specified file is in the index but is missing then it's
       removed. Default behavior is to ignore removed file.

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

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

       Do not try to update submodules. This option is only respected when
       passed before --refresh.

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

       Ignores missing files during a --refresh

   --cacheinfo <mode>,<object>,<path>, --cacheinfo <mode> <object> <path>
       Directly insert the specified info into the index. For backward
       compatibility, you can also give these three arguments as three
       separate parameters, but new users are encouraged to use a
       single-parameter form.

       Read index information from stdin.

       Set the execute permissions on the updated files.

       When this flag is specified, the object names recorded for the
       paths are not updated. Instead, this option sets/unsets the "assume
       unchanged" bit for the paths. When the "assume unchanged" bit is
       on, the user promises not to change the file and allows Git to
       assume that the working tree file matches what is recorded in the
       index. If you want to change the working tree file, you need to
       unset the bit to tell Git. This is sometimes helpful when working
       with a big project on a filesystem that has very slow lstat(2)
       system call (e.g. cifs).

       Git will fail (gracefully) in case it needs to modify this file in
       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.

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

       When one of these flags is specified, the object name recorded for
       the paths are not updated. Instead, these options set and unset the
       "skip-worktree" bit for the paths. See section "Skip-worktree bit"
       below for more information.

   -g, --again
       Runs git update-index itself on the paths whose index entries are
       different from those from the HEAD commit.

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

       Do not create objects in the object database for all <file>
       arguments that follow this flag; just insert their object IDs into
       the index.

       Remove the file from the index even when the working directory
       still has such a file. (Implies --remove.)

       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 path cannot be added. With --replace flag, existing
       entries that conflict with the entry being added are automatically
       removed with warning messages.

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

       Report what is being added and removed from index.

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

       Version 4 performs a simple pathname compression that reduces index
       size by 30%-50% on large repositories, which results in faster load
       time. Version 4 is relatively young (first released in in 1.8.0 in
       October 2012). Other Git implementations such as JGit and libgit2
       may not support it yet.

       Only meaningful with --stdin or --index-info; paths are separated
       with NUL character instead of LF.

   --split-index, --no-split-index
       Enable or disable split index mode. If enabled, the index is split
       into two files, $GIT_DIR/index and $GIT_DIR/sharedindex.<SHA-1>.
       Changes are accumulated in $GIT_DIR/index while the shared index
       file contains all index entries stays unchanged. If split-index
       mode is already enabled and --split-index is given again, all
       changes in $GIT_DIR/index are pushed back to the shared index file.
       This mode is designed for very large indexes that take a
       significant amount of time to read or write.

   --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.untrackedCache configuration variable (see 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.

       Only perform tests on the working directory to make sure untracked
       cache can be used. You have to manually enable untracked cache
       using --untracked-cache or --force-untracked-cache or the
       core.untrackedCache configuration variable afterwards if you really
       want to use it. If a test fails the exit code is 1 and a message
       explains what is not working as needed, otherwise the exit code is
       0 and OK is printed.

       Same as --untracked-cache. Provided for backwards compatibility
       with older versions of Git where --untracked-cache used to imply
       --test-untracked-cache but this option would enable the extension

       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
       use cleaner names. The same applies to directories ending / and
       paths with //


   --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
   "re-match" the stat information of a file with the index, so that you
   can refresh the index for a file that hasn't been changed but where the
   stat entry is out of date.

   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.


   --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:

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

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

   Both --cacheinfo and --info-only behave similarly: the index is updated
   but the object database isn't. --cacheinfo is useful when the object is
   in the database but the file isn't available locally. --info-only is
   useful when the file is available, but you do not wish to update the
   object database.


   --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:

    1. 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.

    2. mode SP type SP sha1 TAB path

       The second format is to stuff git ls-tree output into the index

    3. 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.

   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.

   For example, starting with this index:

       $ git ls-files -s
       100644 8a1218a1024a212bb3db30becd860315f9f3ac52 0       frotz

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

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

   The first line of the input feeds 0 as the mode to remove the path; 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 entries for that path. After
   the above, we would end up with this:

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

   Many operations in Git depend on your filesystem to have an efficient
   lstat(2) implementation, so that st_mtime information for working tree
   files can be cheaply checked to see if the file contents have changed
   from the version recorded in the index file. Unfortunately, some
   filesystems have inefficient lstat(2). If your filesystem is one of
   them, you can set "assume unchanged" bit to paths you have not changed
   to cause Git not to do this check. Note that setting this bit on a path
   does not mean Git will check the contents of the file to see if it has
   changed --- it makes Git to omit any checking and assume it has not
   changed. When you make changes to working tree 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-unchanged option.
   To unset, use --no-assume-unchanged. To see which files have the
   "assume unchanged" bit set, use git ls-files -v (see git-ls-files(1)).

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


   To update and refresh only the files already checked out:

       $ git checkout-index -n -f -a && git update-index --ignore-missing --refresh

   On an inefficient filesystem with core.ignorestat set

           $ git update-index --really-refresh              (1)
           $ git update-index --no-assume-unchanged foo.c   (2)
           $ git diff --name-only                           (3)
           $ edit foo.c
           $ git diff --name-only                           (4)
           M foo.c
           $ git update-index foo.c                         (5)
           $ git diff --name-only                           (6)
           $ edit foo.c
           $ git diff --name-only                           (7)
           $ git update-index --no-assume-unchanged foo.c   (8)
           $ git diff --name-only                           (9)
           M foo.c

       1. forces lstat(2) to set "assume unchanged" bits for paths that
       match index.
       2. mark the path to be edited.
       3. this does lstat(2) and finds index matches the path.
       4. this does lstat(2) and finds index does not match the path.
       5. registering the new version to index sets "assume unchanged"
       6. and it is assumed unchanged.
       7. even after you edit it.
       8. you can tell about the change after the fact.
       9. now it checks with lstat(2) and finds it has been changed.


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

   To elaborate, "reading" means checking for file existence, reading file
   attributes or file content. The working directory version may be
   present or absent. If present, its content may match against the index
   version or not. Writing is not affected by this bit, content safety is
   still first priority. Note that Git can update working directory file,
   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 is
   different from assume-unchanged bit's. Skip-worktree also takes
   precedence over assume-unchanged bit when both are set.


   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 git-config(1)) than
   using the --untracked-cache 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 to true (or false)
   in your $HOME/.gitconfig just once and have it affect all repositories
   you touch.

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


   The command honors core.filemode configuration variable. If your
   repository is on a filesystem whose executable bits are unreliable,
   this should be set to false (see git-config(1)). This causes the
   command to ignore differences in file modes recorded in the index and
   the file mode on the filesystem if they differ only on executable bit.
   On such an unfortunate filesystem, you may need to use git update-index

   Quite similarly, if core.symlinks configuration variable is set to
   false (see git-config(1)), symbolic links are checked out as plain
   files, and this command does not modify a recorded file mode from
   symbolic link to regular file.

   The command looks at core.ignorestat configuration variable. See Using
   "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 by
   something outside Git (file system crawlers and backup systems use
   ctime for marking files processed) (see git-config(1)).

   The untracked cache extension can be enabled by the core.untrackedCache
   configuration variable (see git-config(1)).


   git-config(1), git-add(1), git-ls-files(1)


   Part of the git(1) suite

More Linux Commands

nfsd(7) - special filesystem for controlling Linux NFS serve
The nfsd filesytem is a special filesystem which provides access to the Linux NFS server. The filesystem consists of a single directory which contains a number

argc(n) Variables used by Tcl ______________________________
argc.n - The following global variables are created and managed automatically by the Tcl library. Except where noted below, these variables should normally be t

security(2) - unimplemented system calls - Linux man page...
These system calls are not implemented in the Linux kernel. RETURN VALUE These system calls always return -1 and set errno to ENOSYS. NOTES Note that ftime(3),

clog(3) - natural logarithm of a complex number (Man Page)
The logarithm clog() is the inverse function of the exponential cexp(3). Thus, if y = clog(z), then z = cexp(y). The imaginary part of y is chosen in the interv

guile1(1) a Scheme interpreter (Commands - Linux man page)
GNU Guile is an interpreter for the Scheme programming language. It implements R5RS, providing additional features necessary for real-world use. It is extremely

mro(3pm) - Method Resolution Order - Linux manual page......
The mro namespace provides several utilities for dealing with method resolution order and method caching in general. These interfaces are only available in Perl


cpow(3) - complex power function (Library - Linux man page)
The function calculates x raised to the power z. (With a branch cut for x along the negative real axis.) VERSIONS These functions first appeared in glibc in ver

ogonkify(1) - international support for PostScript (ManPage)
ogonkify does various munging of PostScript files related to printing in different languages. Its main use is to filter the output of Netscape, Mosaic and other

intro.2 - intro(2) - Introduction to system calls - Linux manual page
Section 2 of the manual describes the Linux system calls. A system call is an entry point into the Linux kernel. Usually, system calls are not invoked directly:

Tk_RestrictEvents(3) - filter and selectively delay X events
This procedure is useful in certain situations where applications are only prepared to receive certain X events. After Tk_RestrictEvents is called, Tk_DoOneEven

auparse_get_type(3) - get record's type - Linux manual page
auparse_get_type will return the integer value for the current record of the current event. RETURN VALUE Returns 0 if an error occurs; otherwise, the records ty

We can't live, work or learn in freedom unless the software we use is free.