セットアップと設定
プロジェクトの取得と作成
基本的なスナップショット取得
ブランチとマージ
プロジェクトの共有と更新
検査と比較
パッチ適用
デバッグ
メール
外部システム
サーバー管理
ガイド
- gitattributes
- コマンドラインインターフェースの慣習
- 日常のGit
- よくある質問 (FAQ)
- 用語集
- フック
- gitignore
- gitmodules
- リビジョン
- サブモジュール
- チュートリアル
- ワークフロー
- すべてのガイド...
管理
プルーミングコマンド
- 2.47.1 → 2.49.0 変更なし
-
2.47.0
2024-10-06
- 2.46.1 → 2.46.3 変更なし
-
2.46.0
2024-07-29
- 2.39.1 → 2.45.3 変更なし
-
2.39.0
2022-12-12
- 2.38.1 → 2.38.5 変更なし
-
2.38.0
2022-10-02
説明
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ビットを使用し、コミット時刻は2番目の4バイトの32ビットと、最下位バイトの最下位2ビット(コミット時刻の33番目と34番目のビットを格納)を使用します。
世代データ (ID: {G, D, A, 2 }) (N * 4 バイト) [オプション]
-
この4バイト値のリストは、コミットの修正済みコミット日時オフセットを、コミットデータチャンクと同じ順序で格納します。
-
修正済みコミット日時オフセットが31ビット内に収まらない場合、値の最上位ビットがオンになり、他のビットは修正済みコミット日時のGeneration Data Overflowチャンクへの位置を格納します。
-
世代データチャンクは、互換性のあるバージョンのGitによってコミットグラフファイルが書き込まれた場合のみ存在し、分割されたコミットグラフチェーンの場合、最上位レイヤーにも世代データチャンクがあります。
世代データオーバーフロー (ID: {G, D, O, 2 }) [オプション]
-
この8バイト値のリストは、31ビット以内に格納できない修正済みコミット日時オフセットを持つコミットの修正済みコミット日時オフセットを格納します。
-
世代データオーバーフローチャンクは、世代データチャンクが存在し、かつ少なくとも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ビット整数からなるヘッダーで始まります
-
使用されているハッシュアルゴリズムのバージョン。現在、Murmur3ハッシュの32ビットバージョン(https://en.wikipedia.org/wiki/MurmurHash#Algorithm で正確に記述されているとおりに実装)と、https://doi.org/10.1007/978-3-540-30494-4_26「Bloom Filters in Probabilistic Verification」で記述されているとおり、シード値0x293ae76fと0x7e646e2を使用したダブルハッシュ手法に対応する値2をサポートしています。バージョン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.
履歴に関する注記
Generation Data (GDA2) と Generation Data Overflow (GDO2) チャンクのチャンクIDに数字 *2* が含まれているのは、以前のバージョンのGitが「GDAT」と「GDOV」というIDでこれらのチャンクに誤ったデータを書き込んだ可能性があるためです。IDを変更することで、新しいバージョンのGitは古いチャンクを黙って無視し、不正なデータを信用せずに新しい情報を書き込みます。
GIT
git[1] スイートの一部