我只是想让那个混蛋上擂台。

索引是git中最重要的数据结构之一。 它通过记录路径列表及其对象名称来表示一个虚拟工作树状态，并作为一个staging区域来写出要提交的下一个树对象。 这个状态是“虚拟的”，因为它不需要匹配工作树中的文件，通常也不匹配。

如果我签出一个特殊的提交，git ls-tree会准确地告诉我应该呈现哪些工作文件/对象吗?在ls-tree中，我们说的是哪种树?

例子

git ls-tree -r -l HEAD
git ls-tree -r -l commit-hash

顺便说一句:ls-tree也适用于不签出(-n)克隆的存储库，其中ls-files不返回任何内容。

https://stackoverflow.com/a/56242906/2623045

https://stackoverflow.com/a/67567058/2623045

我只是想让那个混蛋上擂台。

索引是git中最重要的数据结构之一。 它通过记录路径列表及其对象名称来表示一个虚拟工作树状态，并作为一个staging区域来写出要提交的下一个树对象。 这个状态是“虚拟的”，因为它不需要匹配工作树中的文件，通常也不匹配。

如果我签出一个特殊的提交，git ls-tree会准确地告诉我应该呈现哪些工作文件/对象吗?在ls-tree中，我们说的是哪种树?

例子

git ls-tree -r -l HEAD
git ls-tree -r -l commit-hash

顺便说一句:ls-tree也适用于不签出(-n)克隆的存储库，其中ls-files不返回任何内容。

https://stackoverflow.com/a/56242906/2623045

https://stackoverflow.com/a/67567058/2623045

Git索引是工作目录和存储库之间的临时区域。您可以使用索引构建一组希望一起提交的更改。创建提交时，提交的是当前在这个索引中的内容，而不是工作目录中的内容。

要查看索引内的内容，发出命令:

git status

当您运行git status时，您可以看到哪些文件是暂存的(当前在您的索引中)，哪些文件已被修改但尚未暂存，以及哪些文件完全未被跟踪。

你可以看看这个。谷歌搜索会抛出许多链接，这些链接应该是相当自给自足的。

Git索引是一个二进制文件(通常保存在.git/index中)，包含一个排序的路径名列表，每个路径名都有权限和一个blob对象的SHA1;

Git ls-files可以显示索引的内容。请注意，在Git中索引、阶段和缓存是同一件事:它们可以互换使用。

Git索引，或Git缓存，有3个重要的属性:

索引包含生成单个(唯一确定的)树对象所需的所有信息。 索引可以在它定义的树对象和工作树之间进行快速比较。 它可以有效地表示关于不同树对象之间合并冲突的信息，允许每个路径名与所涉及的树的足够信息相关联，以便在它们之间创建三向合并。

来源:

https://mincong.io/2018/04/28/git-index/ https://medium.com/hackernoon/understanding-git-index-4821a0765cf

逐位分析

我决定做一些测试，以更好地理解格式，并更详细地研究一些领域。

下面的结果与Git版本1.8.5.2和2.3相同。

我已经标记了一些我不确定/没有发现TODO的地方:请随时补充这些地方。

正如其他人提到的，索引存储在.git/index下，而不是作为标准树对象，它的格式是二进制的，并记录在:https://github.com/git/git/blob/master/Documentation/technical/index-format.txt

定义索引的主要结构体位于cache.h，因为索引是用于创建提交的缓存。

设置

当我们开始一个测试存储库时:

git init
echo a > b
git add b
tree --charset=ascii

.git目录如下:

.git/objects/
|-- 78
|   `-- 981922613b2afb6025042ff6bd878ac1994e85
|-- info
`-- pack

如果我们得到唯一对象的内容:

git cat-file -p 78981922613b2afb6025042ff6bd878ac1994e85

得到a，这表明:

索引指向文件内容，因为git add b创建了一个blob对象 它将元数据存储在索引文件中，而不是树对象中，因为只有一个对象:blob(在常规Git对象中，blob元数据存储在树中)

高清分析

现在让我们看看索引本身:

hd .git/index

给:

00000000  44 49 52 43 00 00 00 02  00 00 00 01 54 09 76 e6  |DIRC.... ....T.v.|
00000010  1d 81 6f c6 54 09 76 e6  1d 81 6f c6 00 00 08 05  |..o.T.v. ..o.....|
00000020  00 e4 2e 76 00 00 81 a4  00 00 03 e8 00 00 03 e8  |...v.... ........|
00000030  00 00 00 02 78 98 19 22  61 3b 2a fb 60 25 04 2f  |....x.." a;*.`%./|
00000040  f6 bd 87 8a c1 99 4e 85  00 01 62 00 ee 33 c0 3a  |......N. ..b..3.:|
00000050  be 41 4b 1f d7 1d 33 a9  da d4 93 9a 09 ab 49 94  |.AK...3. ......I.|
00000060

接下来我们将得出结论:

  | 0           | 4            | 8           | C              |
  |-------------|--------------|-------------|----------------|
0 | DIRC        | Version      | File count  | ctime       ...| 0
  | ...         | mtime                      | device         |
2 | inode       | mode         | UID         | GID            | 2
  | File size   | Entry SHA-1                              ...|
4 | ...                        | Flags       | Index SHA-1 ...| 4
  | ...                                                       |

首先是头文件，定义在:struct cache_header:

44 49 52 43: dirc。为什么这是必要的? 00 00 00 02:格式版本:2。索引格式随着时间的推移而发展。目前有多达4个版本。在GitHub上不同计算机之间协作时，索引的格式不应该成为问题，因为裸存储库不存储索引:它是在克隆时生成的。 00 00 00 01:索引上的文件数:只有一个，b。

接下来开始一个由struct cache_entry定义的索引项列表，这里我们只有一个。它包含:

a bunch of file metadata: 8 byte ctime, 8 byte mtime, then 4 byte: device, inode, mode, UID and GID. Note how: ctime and mtime are the same (54 09 76 e6 1d 81 6f c6) as expected since we haven't modified the file The first bytes are seconds since EPOCH in hex: date --date="@$(printf "%x" "540976e6")" Gives: Fri Sep 5 10:40:06 CEST 2014 Which is when I made this example. The second 4 bytes are nanoseconds. UID and GID are 00 00 03 e8, 1000 in hex: a common value for single user setups. All of this metadata, most of which is not present in tree objects, allows Git to check if a file has changed quickly without comparing the entire contents. at the beginning of line 30: 00 00 00 02: file size: 2 bytes (a and \n from echo) 78 98 19 22 ... c1 99 4e 85: 20 byte SHA-1 over the previous content of the entry. Note that according to my experiments with the assume valid flag, the flags that follow it are not considered in this SHA-1. 2 byte flags: 00 01 1 bit: assume valid flag. My investigations indicate that this poorly named flag is where git update-index --assume-unchanged stores its state: https://stackoverflow.com/a/28657085/895245 1 bit extended flag. Determines if the extended flags are present or not. Must be 0 on version 2 which does not have extended flags. 2 bit stage flag used during merge. Stages are documented in man git-merge: 0: regular file, not in a merge conflict 1: base 2: ours 3: theirs During a merge conflict, all stages from 1-3 are stored in the index to allow operations like git checkout --ours. If you git add, then a stage 0 is added to the index for the path, and Git will know that the conflict has been marked as solved. TODO: check this. 12 bit length of the path that will follow: 0 01: 1 byte only since the path was b 2 byte extended flags. Only meaningful if the "extended flag" was set on the basic flags. TODO. 62 (ASCII b): variable length path. Length determined in the previous flags, here just 1 byte, b.

然后是一个00:1-8字节的零填充，这样路径将以空结束，索引将以8字节的倍数结束。这只发生在索引版本4之前。

没有使用扩展。Git知道这一点，因为文件中没有足够的空间用于校验和。

最后有一个20字节的校验和ee 33 c0 3a ..09 ab 49 94的索引内容。

在回应@ciro-santilli-%e9%83%9d%e6%b5%b7% 4%b8%9c%e5%86% a07 %8a%b6% 97% 855 %85%ad%e5%9b%9b%e4%ba%8b%e4%bb%b6% b3% 95b %e5% e5%8a%9f的指数，am分享输出为其中一个TODO。

如果你添加，那么阶段0将被添加到该路径的索引中，git将知道冲突已被标记为已解决。托朵:检查这个。”

更具体地说，是不同的合并阶段。

0:普通文件，不存在合并冲突 1:基础 2:我们的 3:他们的

关于各个阶段的详细数字表示，在这种情况下一个文件有冲突。

$ git ls-files -s
100644 f72d68f0d10f6efdb8adc8553a1df9c0444a0bec 0       vars/buildComponent.groovy

$ git stash list
stash@{0}: WIP on master: c40172e turn off notifications, temporarily

$ git stash apply
Auto-merging vars/commonUtils.groovy
Auto-merging vars/buildComponent.groovy
CONFLICT (content): Merge conflict in vars/buildComponent.groovy

$ git ls-files -s
100644 bc48727339d36f5d54e14081f8357a0168f4c665 1       vars/buildComponent.groovy
100644 f72d68f0d10f6efdb8adc8553a1df9c0444a0bec 2       vars/buildComponent.groovy
100644 24dd5be1783633bbb049b35fc01e8e88facb20e2 3       vars/buildComponent.groovy