git-diff-index - 比较树和工作树或索引

将树对象中发现的 blob 的内容和模式与工作树中的相应跟踪文件或索引中的相应路径进行比较。 如果存在 <路径> 参数，则只比较与这些模式匹配的路径。 否则，将比较所有跟踪文件。

你可以选择是完全信任索引文件（使用 --cached 标志），还是要求 diff 逻辑将任何与统计状态不匹配的文件显示为 "暂定更改"。 这两种操作都非常有用。

如果指定了 --cached，则可以询问：

举个例子，假设你在工作目录中工作，更新了索引中的一些文件，准备提交。你想知道你 要 提交的内容，而不需要写一个新的树对象并进行比较

示例：假设我把 commit.c 重命名为 git-commit.c，并执行了 update-index 使其在索引文件中生效。 由于索引文件与我的工作目录一致，所以`git diff-files`根本不会显示任何内容。但使用 'git diff-index ' 就可以：

不难看出，以上是重命名。

事实上，git diff-index --cached 应当 总是完全等同于实际执行 git write-tree 并进行比较。只不过，这个方法更适合只想查看当前位置的情况。

因此，当你问自己 “我已经标记了哪些内容要提交，与之前的树有什么不同” 时，使用 git diff-index --cached 基本上是非常有用的。

“非缓存” 模式采用的是另一种方法，而且可能是两种模式中最有用的一种，因为它的功能无法用 git write-tree + git diff-tree 来模拟。因此这是默认模式。 非缓存版本提出的问题是：

这显然也是一个非常有用的问题，因为它会告诉你*可能*提交的内容。同样，输出结果与 git diff-tree -r 的输出结果完全吻合，但又有所变化。

问题在于，如果某个文件与索引不匹配，我们就不会为它建立备份存储，我们会使用 “全零” sha1 来显示这一点。比方说，你编辑了 kernel/sched.c，但实际上还没有执行 git update-index --没有与新状态相关联的 “对象”，你就会得到：

也就是说，它显示树已经改变，而且 kernel/sched.c 不是最新的，可能包含新的内容。全零的 sha1 意味着要获得真正的差异，需要直接查看工作目录中的对象，而不是进行对象间的差异。

属于 git[1] 文档