gitformat-pack(5) Manual Page

有効なオブジェクトタイプは以下のとおりです:

タイプ5は、将来の拡張用に予約されています。 タイプ0は無効です。

このドキュメントでは、負でない整数で、「サイズエンコーディング」(size encoding)を使用します。つまりそれは、 各バイトから、下位7ビットを使用して結果の整数を形成します。 最上位ビットが1である限り、この処理は続行されます。 MSB 0 のバイトは、最後の7ビットを提供します。これら7ビットのチャンクは連結されます。 後の値の方が上位です。

このサイズエンコーディング(size encoding)を、このドキュメントでも使用されている「オフセットエンコーディング」(offset encoding)と混同しないでください。

概念的には、commit、tree、tag、blobの4つのオブジェクトタイプしかありません。 ただし、スペースを節約するために、オブジェクトを別の「ベース」(base)オブジェクトの「デルタ」(delta)として格納できます。 これらの表現には、パックファイルでのみ有効な新しいタイプの ref-delta および ofs-delta が割り当てられます。

ofs-deltaとref-deltaはどちらも、オブジェクトを再構築するために別のオブジェクト(「ベースオブジェクト」と呼ばれる)に適用される「デルタ」を格納します。 それらの違いは、ref-deltaがベースオブジェクト名を直接エンコードすることです。 ベースオブジェクトが同じパックにある場合、ofs-deltaは代わりにパック内のベースオブジェクトのオフセットをエンコードします。

同一パックに含まれている場合は、ベースオブジェクトを削除することもできます。 ref-deltaは、パック外のオブジェクト(つまり、いわゆる「薄いパック」(thin pack)）を参照することもできます。 ただし、ディスクに保存する場合は、循環依存を回避するためにパックを自己完結型にする必要があります。

The delta data starts with the size of the base object and the size of the object to be reconstructed. These sizes are encoded using the size encoding from above. The remainder of the delta data is a sequence of instructions to reconstruct the object from the base object. If the base object is deltified, it must be converted to canonical form first. Each instruction appends more and more data to the target object until it’s complete. There are two supported instructions so far: one for copying a byte range from the source object and one for inserting new data embedded in the instruction itself.

各命令の長さは可変です。 命令タイプは、最初のオクテット(訳注:1バイト(8ビット))のビット7(訳注:つまりこのバイトの最上位ビット)によって決定されます。 以下の図は、RFC 1951（Deflate compressed data format;圧縮データ形式の解凍）の規則に従います。

パックされたオブジェクトのヘッダー:

(C + 1) * 12 bytes providing the chunk offsets: First 4 bytes describe chunk id. Value 0 is a terminating label. Other 8 bytes provide offset in current file for chunk to start. (Chunks are provided in file-order, so you can infer the length using the next chunk position if necessary.)

CHUNK DATA:

OID Fanout (ID: {O, I, D, F}) The ith entry, F[i], stores the number of OIDs with first byte at most i. Thus F[255] stores the total number of objects.

OID Lookup (ID: {O, I, D, L}) The OIDs for all objects in the MIDX are stored in lexicographic order in this chunk.

Object Offsets (ID: {O, O, F, F}) Stores two 4-byte values for every object. 1: The pack-int-id for the pack storing this object. 2: The offset within the pack. If all offsets are less than 2^{32, then the large offset chunk will not exist and offsets are stored as in IDX v1. If there is at least one offset value larger than 2}32-1, then the large offset chunk must exist, and offsets larger than 2^31-1 must be stored in it instead. If the large offset chunk exists and the 31st bit is on, then removing that bit reveals the row in the large offsets containing the 8-byte offset of this object.

[Optional] Object Large Offsets (ID: {L, O, F, F}) 8-byte offsets into large packfiles.

[Optional] Bitmap pack order (ID: {R, I, D, X}) A list of MIDX positions (one per object in the MIDX, num_objects in total, each a 4-byte unsigned integer in network byte order), sorted according to their relative bitmap/pseudo-pack positions.

TRAILER:

The Bitmapped Packfiles (BTMP) chunk encodes additional information about the objects in the multi-pack index’s reachability bitmap. Recall that objects from the MIDX are arranged in "pseudo-pack" order (see above) for reachability bitmaps.

From the example above, suppose we have packs "a", "b", and "c", with 10, 15, and 20 objects, respectively. In pseudo-pack order, those would be arranged as follows:

When working with single-pack bitmaps (or, equivalently, multi-pack reachability bitmaps with a preferred pack), git-pack-objects(1) performs “verbatim” reuse, attempting to reuse chunks of the bitmapped or preferred packfile instead of adding objects to the packing list.

When a chunk of bytes is reused from an existing pack, any objects contained therein do not need to be added to the packing list, saving memory and CPU time. But a chunk from an existing packfile can only be reused when the following conditions are met:

The BTMP chunk encodes the necessary information in order to implement multi-pack reuse over a set of packfiles as described above. Specifically, the BTMP chunk encodes three pieces of information (all 32-bit unsigned integers in network byte-order) for each packfile p that is stored in the MIDX, as follows:

For example, the BTMP chunk corresponding to the above example (with packs “a”, “b”, and “c”) would look like:

With this information in place, we can treat each packfile as individually reusable in the same fashion as verbatim pack reuse is performed on individual packs prior to the implementation of the BTMP chunk.

到達不能なオブジェクトをリポジトリから削除するために、 Git は git repack -Ad を提供しています(git-repack(1) を参照)。 以下、ドキュメントから引用します:

到達不能なオブジェクトはすぐには削除されません。 すぐに削除してしまうと、 削除しようとしているオブジェクトを参照する可能性のある後続のプッシュと競合する可能性があるためです。 代わりに、 これらの到達不能オブジェクトは緩いオブジェクトとして保存され、 期限切れウィンドウ(expiration window)より古くなるまでそのままの状態で保管されます。 期限切れになった時点で git-prune(1) で削除されます。

Git は、オブジェクトごとの mtime を追跡するために、 これらの到達不能オブジェクトを緩い(loose)オブジェクトに保存する必要があります。 これらの到達不能オブジェクトが 1 つの大きなパックに書き込まれた場合、 そのパックを(その中に含まれるオブジェクトが書き直されたため)リフレッシュするするか、 または到達不能オブジェクトの新しいパックを作成すると、 パックの mtime が更新され、 その中のオブジェクトが有効期限ウィンドウから離脱することは決してありません。 代わりに、 個々のオブジェクトの mtimes を追跡し、 すべての残り物(cruft)オブジェクトが一度に更新される状況を回避するために、 オブジェクトは緩いオブジェクトとして格納されます。

これにより、猶予期間を過ぎていない到達不能オブジェクトがリポジトリに多数含まれている場合に、望ましくない状況が発生する可能性があります。 .git/objects の一部(shard)に大きなディレクトリがあると、 リポジトリのパフォーマンスが低下する可能性があります。 また、 到達不能なオブジェクトがとても沢山ある場合、 i ノードの枯渇につながり、 システム全体のパフォーマンスを低下させる可能性があります。 これらのオブジェクトをパックすることはできないため、 これらのリポジトリは多くの場合、 大量のディスク領域を占有します。 それらは zlib 圧縮することしかできず、デルタ・チェーンに格納することはできないためです。

残り物パック(cruft pack)は、 すべての緩い(loose)オブジェクトを含む単一のパックと一緒に、 オブジェクトごとの mtimes を別のファイルに含めることで、 到達不能なオブジェクトを緩いオブジェクト状態で保存する必要をなくします。

残り物パックは、 新しいパックを生成するときに git repack --cruft によって書き込まれます。 注意: git repack --cruft は古典的なオールインワンの再パックであることに注意してください。 つまり、結果のパック内のすべてが到達可能であり、 他のすべては到達不能です。 --cruft オプションを記述すると、git repack に対して、前のステップでパックされなかったオブジェクトのみを含む別のパックを生成するように指示されます (これは、すべての到達不能オブジェクトを一緒にパックすることと同じです)。 これは以下のとおりに進行します:

このモードは、 残り物パック(cruft pack)を作成するように指示されたときに、 git-repack(1) によって内部的に呼び出されます。 重要なことは、コア内に保持されたパックのセットは、 再パックによって削除されないパックのセットであることで、 つまり、リポジトリの到達可能なすべてのオブジェクトが含まれています。

リポジトリに既に残り物パック(cruft pack)がある場合、 git repack --cruft は通常、 それにオブジェクトを追加するだけです。 これに対する例外は、 git repack に --cruft-expiration オプションが与えられた場合です。 これにより生成された残り物パックは、 後で git-gc(1) がそれらのオブジェクトを期限切れにするのを待つ代わりに、 期限切れのオブジェクトを省略できます。

通常、 期限切れの到達不能オブジェクトの削除を担当するのは git-gc(1) です。

この設計の注目すべき代替案は以下のとおりです:

mtime データの配置においては、 .idx 形式の複雑化を避けるために、 パックに関連付けられた新しい補助ファイルが選択されました。 .idx 形式がオプションのデータ・チャンクのサポートを獲得したならば、 .mtimes 形式を .idx 自体に統合することは理にかなっているかもしれません。