设置和配置
获取和创建项目
基本快照
分支与合并
共享和更新项目
检查和比较
打补丁
调试
电子邮件
外部系统
服务器管理
指南
管理
底层命令
- 2.47.1 → 2.50.1 无更改
-
2.47.0
2024-10-06
- 2.46.1 → 2.46.4 无更改
-
2.46.0
2024-07-29
- 2.39.1 → 2.45.4 无变更
-
2.39.0
2022-12-12
- 2.38.1 → 2.38.5 无更改
-
2.38.0
2022-10-02
描述
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,其余位存储 Extra Edge List 块中的数组位置。
-
接下来的 8 字节存储提交的拓扑级别(生成号 v1)和自 EPOCH 以来的提交时间(秒)。生成号使用前 4 字节的最高 30 位,而提交时间使用后 4 字节的 32 位,以及最低字节的最低 2 位,存储提交时间的第 33 和 34 位。
生成数据 (ID: {G, D, A, 2 }) (N * 4 字节) [可选]
-
这个 4 字节值列表存储提交的修正提交日期偏移量,其排列顺序与提交数据块相同。
-
如果修正提交日期偏移量无法存储在 31 位内,则该值最高位为 1,其余位存储修正提交日期在 Generation Data Overflow 块中的位置。
-
生成数据块仅在兼容版本的 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,它对应于精确按照 https://en.wikipedia.org/wiki/MurmurHash#Algorithm 中描述实现的 32 位 murmur3 哈希版本,以及使用种子值 0x293ae76f 和 0x7e646e2 的双重哈希技术,如 https://doi.org/10.1007/978-3-540-30494-4_26 “概率验证中的布隆过滤器” 中所述。版本 1 的布隆过滤器存在一个错误,当 char 类型为有符号且仓库中路径名包含字符 >= 0x80 时会出现;Git 支持读写这些过滤器,但此功能将在未来的 Git 版本中移除。
-
路径被哈希的次数,从而也是累积确定文件是否存在于提交中的位数。
-
布隆过滤器中每个条目的最小位数 b。如果过滤器包含 n 个条目,则过滤器大小是包含 n*b 位的最小 64 位字数。
-
-
块的其余部分是按字典序排列的所有提交的计算布隆过滤器的串联。
-
注意:没有更改或超过 512 次更改的提交,其布隆过滤器长度为一,所有位分别设置为零或一。
-
BDAT 块存在当且仅当 BIDX 存在时。
历史说明
生成数据 (GDA2) 和生成数据溢出 (GDO2) 块的块 ID 中包含数字 *2*,因为早期版本的 Git 在这些 ID 为 "GDAT" 和 "GDOV" 的块中写入了可能错误的数据。通过更改 ID,新版本的 Git 将默默地忽略这些旧块并写入新信息,而不信任不正确的数据。