objects to be pruned immediately don't have to be loosened
[gitweb.git] / Documentation / git-update-index.txt
index fdcb8bea7dd9bd9c2157a1f7698b31328a387f84..25e0bbea86caf1234da1746d4a2082cfb80129bd 100644 (file)
@@ -3,16 +3,20 @@ git-update-index(1)
 
 NAME
 ----
-git-update-index - Modifies the index or directory cache
+git-update-index - Register file contents in the working tree to the index
 
 
 SYNOPSIS
 --------
-'git-update-index'
-            [--add] [--remove | --force-remove] [--replace] 
-            [--refresh [-q] [--unmerged] [--ignore-missing]]
+[verse]
+'git update-index'
+            [--add] [--remove | --force-remove] [--replace]
+            [--refresh] [-q] [--unmerged] [--ignore-missing]
             [--cacheinfo <mode> <object> <file>]\*
             [--chmod=(+|-)x]
+            [--assume-unchanged | --no-assume-unchanged]
+            [--ignore-submodules]
+            [--really-refresh] [--unresolve] [--again | -g]
             [--info-only] [--index-info]
             [-z] [--stdin]
             [--verbose]
@@ -24,7 +28,10 @@ Modifies the index or directory cache. Each file mentioned is updated
 into the index and any 'unmerged' or 'needs updating' state is
 cleared.
 
-The way "git-update-index" handles files it is told about can be modified
+See also linkgit: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:
 
 OPTIONS
@@ -37,7 +44,7 @@ OPTIONS
 --remove::
        If a specified file is in the index but is missing then it's
        removed.
-       Default behaviour is to ignore removed file.
+       Default behavior is to ignore removed file.
 
 --refresh::
        Looks at the current index and checks to see if merges or
@@ -46,11 +53,15 @@ OPTIONS
 -q::
         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.
+       'git-update-index' continue anyway.
+
+--ignore-submodules::
+       Do not try to update submodules.  This option is only respected
+       when passed before --refresh.
 
 --unmerged::
         If --refresh finds unmerged changes in the index, the default
-        behavior is to error out.  This option makes git-update-index 
+       behavior is to error out.  This option makes 'git-update-index'
         continue anyway.
 
 --ignore-missing::
@@ -58,12 +69,44 @@ OPTIONS
 
 --cacheinfo <mode> <object> <path>::
        Directly insert the specified info into the index.
-       
+
 --index-info::
         Read index information from stdin.
 
 --chmod=(+|-)x::
-        Set the execute permissions on the updated files.        
+        Set the execute permissions on the updated files.
+
+--assume-unchanged::
+--no-assume-unchanged::
+       When these flags are specified, the object names recorded
+       for the paths are not updated.  Instead, these options
+       set and unset the "assume unchanged" bit for the
+       paths.  When the "assume unchanged" bit is on, git stops
+       checking the working tree files for possible
+       modifications, so you need to manually unset the bit to
+       tell git when you change the working tree file. This is
+       sometimes helpful when working with a big project on a
+       filesystem that has very slow lstat(2) system call
+       (e.g. cifs).
++
+This option can be also used as a coarse file-level mechanism
+to ignore uncommitted changes in tracked files (akin to what
+`.gitignore` does for untracked files).
+You should remember that an explicit 'git add' operation will
+still cause the file to be refreshed from the working tree.
+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.
+
+-g::
+--again::
+       Runs 'git-update-index' itself on the paths whose index
+       entries are different from those from the `HEAD` commit.
+
+--unresolve::
+       Restores the 'unmerged' or 'needs updating' state of a
+       file during a merge if it was cleared by accident.
 
 --info-only::
        Do not create objects in the object database for all
@@ -76,10 +119,10 @@ OPTIONS
 
 --replace::
        By default, when a file `path` exists in the index,
-       git-update-index refuses an attempt to add `path/file`.
+       '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 conflicts with the entry being added are
+       that conflict with the entry being added are
        automatically removed with warning messages.
 
 --stdin::
@@ -94,13 +137,13 @@ OPTIONS
        Only meaningful with `--stdin`; paths are separated with
        NUL character instead of LF.
 
---::
+\--::
        Do not interpret any more arguments as options.
 
 <file>::
        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     
+       `./file` and `dir/./file`. If you don't want this, then use
        cleaner names.
        The same applies to directories ending '/' and paths with '//'
 
@@ -112,7 +155,7 @@ up-to-date for mode/content changes. But what it *does* do is to
 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
+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
@@ -123,7 +166,9 @@ merging.
 
 To pretend you have a file with mode and sha1 at path, say:
 
-   $ git-update-index --cacheinfo mode sha1 path
+----------------
+$ 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.
@@ -134,11 +179,129 @@ 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.
 
+
+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.
+
+    . 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 SHA1 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
+------------
+
+
+Using ``assume unchanged'' bit
+------------------------------
+
+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`.
+
+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").
+
+
 Examples
 --------
 To update and refresh only the files already checked out:
 
-   git-checkout-index -n -f -a && git-update-index --ignore-missing --refresh
+----------------
+$ 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" bit.
+<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.
 
 
 Configuration
@@ -146,11 +309,31 @@ Configuration
 
 The command honors `core.filemode` configuration variable.  If
 your repository is on an filesystem whose executable bits are
-unreliable, this should be set to 'false'.  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
+unreliable, this should be set to 'false' (see linkgit: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 --chmod=`.
+need to use 'git-update-index --chmod='.
+
+Quite similarly, if `core.symlinks` configuration variable is set
+to 'false' (see linkgit: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 linkgit:git-config[1]).
+
+
+SEE ALSO
+--------
+linkgit:git-config[1],
+linkgit:git-add[1]
+
 
 Author
 ------
@@ -162,5 +345,4 @@ Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel
 
 GIT
 ---
-Part of the gitlink:git[7] suite
-
+Part of the linkgit:git[1] suite