设置和配置
获取和创建项目
基本快照
分支和合并
共享和更新项目
检查和比较
修补
调试
邮件
外部系统
服务器管理
指南
管理
底层命令
- 2.47.0 10/06/24
- 2.46.1 → 2.46.2 无更改
- 2.46.0 07/29/24
- 2.39.1 → 2.45.2 无更改
- 2.39.0 12/12/22
- 2.38.1 → 2.38.5 无更改
- 2.38.0 10/02/22
描述
Git 提交图存储提交 OID 列表以及一些关联的元数据,包括:
-
提交的生成号。
-
根树 OID。
-
提交日期。
-
提交的父级,使用图文件中的位置引用存储。
-
如果请求,则提交的布隆过滤器包含在提交和其第一个父级之间更改的路径。
这些位置引用存储为无符号 32 位整数,对应于提交 OID 列表中的数组位置。由于我们用来跟踪父级的某些特殊常量,我们最多可以存储 (1 << 30) + (1 << 29) + (1 << 28) - 1(约 18 亿)个提交。
提交图文件具有以下格式
为了允许扩展向图添加额外数据,我们将主体组织成“块”并在主体的开头提供一个二进制查找表。标题包含某些值,例如块数和哈希类型。
所有多字节数字都采用网络字节序。
头部
4-byte signature: The signature is: {'C', 'G', 'P', 'H'}
1-byte version number: Currently, the only valid version is 1.
1-byte Hash Version We infer the hash length (H) from this value: 1 => SHA-1 2 => SHA-256 If the hash type does not match the repository's hash algorithm, the commit-graph file should be ignored with a warning presented to the user.
1-byte number (C) of "chunks"
1-byte number (B) of base commit-graphs We infer the length (H*B) of the Base Graphs chunk from this value.
块查找
(C + 1) * 12 bytes listing the table of contents for the chunks: First 4 bytes describe the chunk id. Value 0 is a terminating label. Other 8 bytes provide the byte-offset in current file for chunk to start. (Chunks are ordered contiguously in the file, so you can infer the length using the next chunk position if necessary.) Each chunk ID appears at most once.
The CHUNK LOOKUP matches the table of contents from the chunk-based file format, see gitformat-chunk[5]
The remaining data in the body is described one chunk at a time, and these chunks may be given in any order. Chunks are required unless otherwise specified.
块数据
OID 扇出 (ID: {O, I, D, F}) (256 * 4 字节)
The ith entry, F[i], stores the number of OIDs with first byte at most i. Thus F[255] stores the total number of commits (N).
OID 查找 (ID: {O, I, D, L}) (N * H 字节)
The OIDs for all commits in the graph, sorted in ascending order.
提交数据 (ID: {C, D, A, T }) (N * (H + 16) 字节)
-
前 H 个字节用于根树的 OID。
-
接下来的 8 个字节用于第 i 个提交的前两个父级的位置。如果该位置没有父级,则存储值 0x70000000。如果有多于两个父级,则第二个值的最重要位为 1,其他位存储到“额外边列表”块中的数组位置。
-
接下来的 8 个字节存储提交的拓扑级别(生成号 v1)和自纪元以来的提交时间(以秒为单位)。生成号使用前 4 个字节中较高的 30 位,而提交时间使用后 4 个字节的 32 位,以及最低字节的最低 2 位,存储提交时间的第 33 位和第 34 位。
生成数据 (ID: {G, D, A, 2 }) (N * 4 字节) [可选]
-
此 4 字节值的列表存储提交的已更正提交日期偏移量,其排列顺序与提交数据块相同。
-
如果无法在 31 位内存储已更正的提交日期偏移量,则该值的最重要位为 1,其他位存储到“生成数据溢出”块中的已更正提交日期的位置。
-
仅当提交图文件由兼容版本的 Git 编写时,才会出现生成数据块,并且在提交图链拆分的情况下,最顶层也具有生成数据块。
生成数据溢出 (ID: {G, D, O, 2 }) [可选]
-
此 8 字节值的列表存储无法在 31 位内存储的提交的已更正提交日期偏移量。
-
仅当存在生成数据块且至少有一个已更正的提交日期偏移量无法在 31 位内存储时,才会出现生成数据溢出块。
额外边列表 (ID: {E, D, G, E}) [可选]
This list of 4-byte values store the second through nth parents for all octopus merges. The second parent value in the commit data stores an array position within this list along with the most-significant bit on. Starting at that array position, iterate through this list of commit positions for the parents until reaching a value with the most-significant bit on. The other bits correspond to the position of the last parent.
布隆过滤器索引 (ID: {B, I, D, X}) (N * 4 字节) [可选]
-
第 i 个条目 BIDX[i] 存储从提交 0 到提交 i(含)的所有布隆过滤器中的字节数(以字典顺序排列)。第 i 个提交的布隆过滤器跨越从 BIDX[i-1] 到 BIDX[i](加上标题长度),其中 BIDX[-1] 为 0。
-
如果不存在 BDAT 块,则忽略 BIDX 块。
布隆过滤器数据 (ID: {B, D, A, T}) [可选]
-
它以包含三个无符号 32 位整数的标题开头
-
正在使用的哈希算法的版本。我们目前支持值 2,它对应于 32 位版本的 murmur3 哈希,其实现方式与 https://en.wikipedia.org/wiki/MurmurHash#Algorithm 中描述的完全相同,以及使用种子值 0x293ae76f 和 0x7e646e2 的双哈希技术,如 https://doi.org/10.1007/978-3-540-30494-4_26“概率验证中的布隆过滤器”中所述。版本 1 布隆过滤器存在一个错误,当 char 带符号且存储库具有路径名称(其字符 >= 0x80)时会出现;Git 支持读取和写入它们,但此功能将在 Git 的未来版本中删除。
-
路径被哈希的次数,以及累积确定文件是否存在于提交中的位位置数。
-
布隆过滤器中每个条目的最小位数 b。如果过滤器包含 n 个条目,则过滤器大小是包含 n*b 位的最小 64 位字数。
-
-
块的其余部分是所有计算出的布隆过滤器(以字典顺序排列)的串联。
-
注意:没有更改或更改超过 512 次的提交的布隆过滤器长度为 1,所有位都设置为 0 或 1。
-
当且仅当存在 BIDX 时,BDAT 块才会出现。
历史记录
生成数据 (GDA2) 和生成数据溢出 (GDO2) 块在其块 ID 中包含数字 2,因为 Git 的早期版本在这些块中写入可能存在错误的数据,其 ID 为“GDAT”和“GDOV”。通过更改 ID,较新版本的 Git 将静默忽略这些较旧的块并写入新信息,而不信任不正确的数据。
GIT
git[1] 套件的一部分