git-update-index - 将工作区中的文件内容注册到索引中

修改索引。提到的每个文件都会更新到索引中，任何 “未合并” 或 “需要更新” 的状态都会被清除。

参见 git-add[1]，以获取更友好的索引操作方法。

git update-index 处理文件的方式可以通过各种选项来修改：

--refresh 选项不会计算新的 sha1 文件，也不会为模式/内容更改更新索引。但是，它要做的是将文件的统计信息与索引 “重新匹配”，以便您可以刷新未更改但统计条目已过期的文件的索引。

例如，您需要在执行 git read-tree 后执行此操作，以便将统计索引详情与适当的文件联系起来。

--cacheinfo 用于注册不在当前工作目录中的文件。 这对最小检查合并很有用。

假设路径下有一个文件，带有模式和 sha1，例如：

--info-only 用于注册文件而不将其放入对象数据库。 这对仅有状态的仓库非常有用。

--cacheinfo 和 --info-only 的行为类似：索引会更新，但对象数据库不会更新。 当对象在数据库中但文件在本地不可用时，--cacheinfo 很有用。 当文件可用但不希望更新对象数据库时，--info-only 很有用。

--index-info 是一种更强大的机制，可让你从标准输入中输入多个条目定义，专为脚本设计。 它可以接受三种格式的输入：

若要在索引中输入更高一级的条目，应首先删除路径，为路径输入模式 =0 的条目，然后按第三种格式输入必要的输入行。

例如，从这个索引开始：

你可以向 --index-info 输入以下内容：

输入的第一行输入 0 作为删除路径的模式；只要格式正确，SHA-1 并不重要。 然后，第二行和第三行分别输入该路径的阶段 1 和阶段 2 条目。 经过上述操作后，我们将得到以下结果：

Git 中的许多操作都依赖于文件系统高效的 lstat(2) 实现，这样就能以低成本检查工作树文件的 st_mtime 信息，查看文件内容是否与索引文件中记录的版本有所变化。 遗憾的是，有些文件系统的 lstat(2) 效率很低。 如果你的文件系统属于这种情况，你可以在没有更改过的路径上设置 “假设未更改” 位，这样 Git 就不会进行这种检查了。 需要注意的是，在路径上设置这个位并不意味着 Git 会检查文件的内容是否有变化，而是让 Git 忽略任何检查，假设文件 没有 变化。 当你对工作区文件进行修改时，你必须在修改之前或之后，通过丢弃 “假定不变” 位来明确告知 Git。

要设置 “假设不变” 位，请使用 --assume-unchanged 选项。 要取消设置，使用 --no-assume-unchanged 选项。使用 git ls-files -v 查看哪些文件设置了 “假设不变” 位（参见 git-ls-files[1]）。

该命令会查看 core.ignorestat 配置变量。 为真时，用 git update-index paths... 更新的路径，以及用其他同时更新索引和工作区的 Git 命令（例如 git apply --index, git checkout-index -u, 和 git read-tree -u）更新的路径，都会被自动标记为 “假设不变”。 请注意，如果 git update-index --refresh 发现工作区文件与索引匹配，“假设不变” 位将不会被设置（如果想标记为 “假设不变”，请使用 git update-index --really-refresh）。

有时用户会将假定不变位与跳过工作区位混淆。 关于两者的区别，请参阅下文 “跳过工作区位” 部分的最后一段。

只更新和刷新已签出的文件：

跳过工作区位可以用一句（长）话来定义：告诉 Git 在合理的情况下避免将文件写入工作目录，当文件不在工作目录中时，将其视为不变文件。

请注意，并非所有的 Git 命令都会关注这一点，有些命令仅部分支持这一点。

git-sparse-checkout[1] 命令为配置和处理跳过工作树位提供了更简便的方法。 如果你想缩减工作区，只处理仓库中的部分文件，我们强烈建议你使用 git-sparse-checkout[1] 而不是底层的 update-index 和 read-tree 原语。

跳过工作树位的主要目的是实现稀疏签出，即工作目录中只存在路径的子集。 设置了跳过工作树位后，Git 命令（如 switch 、pull 、merge ）将避免写入这些文件。 不过，在一些重要的情况下，比如合并或重置过程中的冲突，这些命令有时还是会写入这些文件。 Git 命令也会避免将缺少这些文件视为有意删除；例如 git add -u 不会阶段性删除这些文件，而 git commit -a 也不会提交删除这些文件。

虽然这个位看起来与假定未修改位相似，但目标不同。 假定未修改位用于将文件保留在工作树中，但让 Git 忽略检查文件是否被修改，并假定文件未被修改（当然，如果 Git 可以在不统计文件的情况下确定文件已被修改，它也可以自由地记录这些修改）。 skip-worktree 则告诉 Git 忽略文件的缺失，尽可能避免使用通常会更新大部分工作目录的命令（如 checkout 、switch 、pull 等）更新文件，并且不在提交中记录文件的缺失。 需要注意的是，在稀疏签出中（通过 git sparse-checkout 或将 core.sparseCheckout 配置为 true 设置），如果某个文件在索引中被标记为跳过工作区，但在工作区中找到了，Git 会清除该文件的跳过工作区位。

该模式专为拥有超大索引的仓库而设计，旨在减少重复写入这些索引所需的时间。

在这种模式下，索引被分割成两个文件：$GIT_DIR/index 和 $GIT_DIR/sharedindex.<SHA-1>。更改会累积到分割索引的 $GIT_DIR/index，而共享索引文件则包含所有索引条目并保持不变。

当拆分索引中的条目数达到 splitIndex.maxPercentChange 配置变量（参见 git-config[1]）指定的水平时，拆分索引中的所有更改都会被推送回共享索引文件。

每次创建新的共享索引文件时，如果旧的共享索引文件的修改时间早于 splitIndex.sharedIndexExpire 配置变量（参见 git-config[1]）的指定时间，则会被删除。

为避免删除仍在使用的共享索引文件，每次创建或读取基于共享索引文件的新拆分索引时，都会将其修改时间更新为当前时间。

该缓存的目的是加快涉及确定未跟踪文件（如 git status ）的命令的执行速度。

该功能的工作原理是记录工作树目录的 mtime，然后省略读取目录和对 mtime 未发生变化的目录中文件的 stat 调用。要实现这一功能，如果目录中的文件被添加、修改或删除，底层操作系统和文件系统必须更改目录的 st_mtime 字段。

你可以使用`--test-untracked-cache` 选项来测试文件系统是否支持该功能。在旧版本的 Git 中，--untracked-cache 选项曾隐含地执行该测试，但现在已不再如此。

如果你想启用（或禁用）这项功能，使用 core.untrackedCache 配置变量（参见 git-config[1]）比在每个版本库中使用 --untracked-cache 选项来 git update-index 要容易得多，尤其是如果你想在你使用的所有仓库中都这样做的话，因为你只需在 $HOME/.gitconfig 中将配置变量设置为 true （或 false ）一次，它就会影响你接触的所有仓库。

当更改 core.untrackedCache 配置变量时，未跟踪缓存会在下一次命令读取索引时添加到索引中或从索引中移除；而当使用 --[no-|force-]untracked-cache 时，未跟踪缓存会立即添加到索引中或从索引中移除。

在 2.17 之前，untracked 缓存有一个 bug，即用指向另一个目录的符号链接替换一个目录会导致它错误地将 Git 追踪的文件显示为未追踪。参见 git.git 上的 "status: add a failing test showing a core.untrackedCache bug" 。解决这个问题的方法是（将来也可能适用于其他未被发现的 bug）：

当涉及到非跟踪缓存的内部结构时，这个 bug 也会影响到用文件替换目录的非符号链接情况，但还没有报告说这会导致错误的 "git status" 输出。

在某些情况下，由 2.17 之前版本的 Git 编写的现有索引会引用已不存在的目录，这可能会在 "git status" 上打印出许多 "could not open directory" （无法打开目录）的警告。这些警告是针对以前被默默丢弃的现有问题的新警告。

与上述错误一样，解决办法是一次性运行 core.untrackedCache=false 的 "git status" ，以清除剩余的坏数据。

该功能旨在加快工作目录较大的仓库的 Git 操作速度。

它能让 Git 与文件系统监视器（参见 git-fsmonitor--daemon[1] 和 githooks[5] 中的 "fsmonitor-watchman" 部分）协同工作，监视器会告诉 Git 哪些文件被修改了。这样，Git 就不必通过 lstat() 来查找修改过的文件了。

与非跟踪缓存结合使用时，可以避免扫描整个工作目录寻找新文件的成本，从而进一步提高性能。

如果您想启用（或禁用）此功能，使用 core.fsmonitor 配置变量（参见 git-config[1]）比在每个仓库中使用 -git update-index 的 --fsmonitor 选项更方便，尤其是如果您想在您使用的所有仓库中启用（或禁用）此功能，因为您只需在 $HOME/.gitconfig 中设置一次配置变量，就能影响您接触的所有仓库。

更改 core.fsmonitor 配置变量后，文件系统监视器将在下一次命令读取索引时添加到索引或从索引中移除。当使用 --[no-]fsmonitor 时，文件系统监视器会立即添加到索引或从索引中移除。

命令尊重 core.filemode 配置变量。 如果您的仓库位于可执行位不可靠的文件系统上则应将其设置为 false（参见 git-config[1]）。 如果索引中记录的文件模式与文件系统上的文件模式仅在可执行位上不同，则命令会忽略两者之间的差异。 在这种不幸的文件系统上，你可能需要使用 "git update-index --chmod= "。

与此类似，如果将 core.symlinks 配置变量设为 false（参见 git-config[1]），符号链接将作为普通文件签出，此命令不会将记录的文件模式从符号链接修改为普通文件。

该命令会查看 core.ignorestat 配置变量。 请参阅上文 “使用 ‘假设不变’ 位 ”部分。

该命令还会查看 core.trustctime 配置变量。 当 Git 以外的东西（文件系统爬虫和备份系统使用 ctime 来标记处理过的文件）定期修改 inode 变更时间时，这个变量会很有用（参见 git-config[1]）。

非跟踪缓存扩展可以通过 core.untrackedCache 配置变量启用（参见 git-config[1]）。

用户经常尝试使用假设不变和跳过工作区位来告诉 Git 忽略对已跟踪文件的修改。 但这并不尽如人意，因为在执行某些操作时，Git 仍会根据索引检查工作区文件。 一般来说，Git 并不提供忽略被跟踪文件的方法，因此建议使用其他解决方案。

例如，如果要修改的文件是某种配置文件，仓库可以包含一个样本配置文件，然后将其复制到被忽略的文件名中并进行修改。 仓库甚至可以包含一个脚本，将样本文件作为模板，自动修改和复制。

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

属于 git[1] 文档