設定和配置
獲取和建立專案
基本快照
分支與合併
共享和更新專案
檢查和比較
打補丁
除錯
電子郵件
外部系統
伺服器管理
指南
管理
底層命令
- 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 將默默地忽略這些舊塊並寫入新資訊,而不信任不正確的資料。