日本語 ▾ トピック ▾ 最新バージョン ▾ gitformat-commit-graph は 2.47.0 で最終更新されました

名前

gitformat-commit-graph - Git コミットグラフ形式

概要

$GIT_DIR/objects/info/commit-graph
$GIT_DIR/objects/info/commit-graphs/*

説明

Git コミットグラフには、コミット OID のリストと、それに関連するいくつかのメタデータが格納されます。

  • コミットの生成番号。

  • ルートツリーの OID。

  • コミット日時。

  • コミットの親は、グラフファイル内の位置参照を使用して格納されます。

  • 要求された場合、コミットと最初の親の間で変更されたパスを保持するコミットのブルームフィルタ。

これらの位置参照は、コミット OID のリスト内の配列位置に対応する符号なし 32 ビット整数として格納されます。親を追跡するために使用する特別な定数があるため、最大 (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 番目のコミットの最初の 2 つの親の位置用です。その位置に親がない場合は値 0x70000000 を格納します。親が 3 つ以上ある場合、2 番目の値は最上位ビットがオンになり、他のビットは Extra Edge List チャンク内の配列位置を格納します。

  • 次の 8 バイトには、コミットのトポロジカルレベル (世代番号 v1) と、EPOCH からの秒単位のコミット時刻が格納されます。世代番号は最初の 4 バイトの上位 30 ビットを使用し、コミット時刻は次の 4 バイトの 32 ビットと最下位バイトの最下位 2 ビットを使用して、コミット時刻の 33 ビット目と 34 ビット目を格納します。

世代データ (ID: {G, D, A, 2 }) (N * 4 バイト) [オプション]

  • この 4 バイト値のリストは、コミットの修正されたコミット日付オフセットを、コミットデータチャンクと同じ順序で格納します。

  • 修正されたコミット日付オフセットが 31 ビット内に格納できない場合、その値は最上位ビットがオンになり、他のビットは修正されたコミット日付の Generation Data Overflow チャンク内の位置を格納します。

  • Generation Data チャンクは、コミットグラフファイルが互換性のあるバージョンの Git によって書き込まれ、かつ分割コミットグラフチェーンの場合に、最上位レイヤーにも Generation Data チャンクがある場合にのみ存在します。

世代データオーバーフロー (ID: {G, D, O, 2 }) [オプション]

  • この 8 バイト値のリストは、31 ビット内に格納できない修正されたコミット日付オフセットを持つコミットの修正されたコミット日付オフセットを格納します。

  • Generation Data Overflow チャンクは、Generation Data チャンクが存在し、かつ少なくとも 1 つの修正されたコミット日付オフセットが 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}) [オプション]

  • これは、3 つの符号なし 32 ビット整数からなるヘッダーで始まります

    • 使用されているハッシュアルゴリズムのバージョン。現在、値 2 をサポートしています。これは、https://en.wikipedia.org/wiki/MurmurHash#Algorithm で正確に説明されている murmur3 ハッシュの 32 ビットバージョンと、https://doi.org/10.1007/978-3-540-30494-4_26 "Bloom Filters in Probabilistic Verification" で説明されているように、シード値 0x293ae76f と 0x7e646e2 を使用したダブルハッシュ技術に対応します。バージョン 1 のブルームフィルタには、char が符号付きで、リポジトリに 0x80 以上の文字を含むパス名がある場合に発生するバグがあります。Git はそれらの読み書きをサポートしていますが、この機能は将来のバージョンの Git で削除される予定です。

    • パスがハッシュされる回数、したがってファイルがコミットに存在するかどうかを累積的に決定するビット位置の数。

    • ブルームフィルタ内のエントリあたりの最小ビット数 b。フィルタに n 個のエントリが含まれる場合、フィルタサイズは n*b ビットを含む最小の 64 ビットワード数です。

  • チャンクの残りの部分は、辞書順に並べられたコミットに対して計算されたすべてのブルームフィルタの連結です。

  • 注: 変更がないコミット、または 512 を超える変更があるコミットは、長さが 1 のブルームフィルタを持ち、すべてのビットがそれぞれゼロまたは 1 に設定されます。

  • BDAT チャンクは、BIDX が存在する場合にのみ存在します。

ベースグラフリスト (ID: {B, A, S, E}) [オプション]

This list of H-byte hashes describe a set of B commit-graph files that
form a commit-graph chain. The graph position for the ith commit in this
file's OID Lookup chunk is equal to i plus the number of commits in all
base graphs.  If B is non-zero, this chunk must exist.

トレーラー

H-byte HASH-checksum of all of the above.

歴史的注記

世代データ (GDA2) および世代データオーバーフロー (GDO2) チャンクのチャンク ID に番号 2 が含まれているのは、以前のバージョンの Git が「GDAT」および「GDOV」という ID でこれらのチャンクに誤ったデータを書き込んだ可能性があるためです。ID を変更することで、新しいバージョンの Git は古いチャンクを黙って無視し、誤ったデータを信頼せずに新しい情報を書き込みます。

GIT

git[1]スイートの一部

scroll-to-top