日本語 ▾ トピック ▾ 最新バージョン ▾ git-pack-objects は 2.49.0 で最終更新されました

名前

git-pack-objects - オブジェクトのパックアーカイブを作成

概要

git pack-objects [-q | --progress | --all-progress] [--all-progress-implied]
	[--no-reuse-delta] [--delta-base-offset] [--non-empty]
	[--local] [--incremental] [--window=<n>] [--depth=<n>]
	[--revs [--unpacked | --all]] [--keep-pack=<pack-name>]
	[--cruft] [--cruft-expiration=<time>]
	[--stdout [--filter=<filter-spec>] | <base-name>]
	[--shallow] [--keep-true-parents] [--[no-]sparse]
	[--name-hash-version=<n>] < <object-list>

説明

標準入力からオブジェクトのリストを読み込み、指定されたベースネームで1つ以上のパックアーカイブをディスクに書き出すか、パックアーカイブを標準出力に書き出します。

パックアーカイブは、2つのリポジトリ間で一連のオブジェクトを転送するための効率的な方法であり、アクセス効率の良いアーカイブ形式でもあります。パックアーカイブでは、オブジェクトは圧縮された全体として保存されるか、他のオブジェクトからの差分として保存されます。後者はしばしば「デルタ」と呼ばれます。

パックアーカイブ形式 (.pack) は自己完結型に設計されており、追加情報なしで展開できます。そのため、デルタが依存する各オブジェクトはパック内に存在する必要があります。

パック内のオブジェクトへの高速なランダムアクセスを可能にするために、パックインデックスファイル (.idx) が生成されます。インデックスファイル (.idx) とパックアーカイブ (.pack) の両方を $GIT_OBJECT_DIRECTORY の pack/ サブディレクトリ (または $GIT_ALTERNATE_OBJECT_DIRECTORIES のいずれかのディレクトリ) に配置することで、Git はパックアーカイブから読み込むことができます。

_git unpack-objects_ コマンドは、パックアーカイブを読み込み、パックに含まれるオブジェクトを「ワンファイル・ワンオブジェクト」形式に展開できます。これは、スマートプルコマンドが、効率的なネットワーク転送のためにオンザフライでパックを作成する際によく行われます。

オプション

base-name

生成されるファイルの名前を決定するために <base-name> を使用して、ファイルのペア (.pack と .idx) に書き込みます。このオプションが使用されると、ペア内の2つのファイルは <base-name>-<SHA-1>.{pack,idx} ファイルに書き込まれます。<SHA-1> はパックの内容に基づいたハッシュであり、コマンドの標準出力に書き込まれます。

--stdout

パックの内容 (.pack ファイルに書き込まれるはずだったもの) を標準出力に書き出します。

--revs

個々のオブジェクト名の代わりに、標準入力からリビジョン引数を読み込みます。リビジョン引数は、_git rev-list_ が `--objects` フラグと共に `commit` 引数を使用して出力するオブジェクトのリストを構築するのと同じ方法で処理されます。結果のリストにあるオブジェクトはパックされます。リビジョンに加えて、`--not` または `--shallow <SHA-1>` 行も受け入れられます。

--unpacked

これは `--revs` を意味します。標準入力から読み込んだリビジョン引数のリストを処理する際、パックされるオブジェクトを、まだパックされていないものに限定します。

--all

これは `--revs` を意味します。標準入力から読み込んだリビジョン引数のリストに加えて、`refs/` 配下のすべての参照が含まれるように指定されたかのように扱います。

--include-tag

参照するオブジェクトが結果のパックファイルに含まれていた場合、要求されていない注釈付きタグを含めます。これは、新しいタグをネイティブ Git クライアントに送信するのに役立ちます。

--stdin-packs

オブジェクト名やリビジョン引数の代わりに、標準入力からパックファイル (例: `pack-1234abcd.pack`) のベースネームを読み込みます。結果のパックには、含まれるパック (`^` で始まらないもの) にリストされているすべてのオブジェクトが含まれ、除外されるパック (`^` で始まるもの) にリストされているオブジェクトは除外されます。

`--revs` または `--revs` を意味するオプション (例: `--all`) とは互換性がありませんが、`--unpacked` は互換性があります。

--cruft

到達不能なオブジェクトを、`.mtimes` ファイルの存在によって示される別の「cruft」パックにパックします。通常、`git repack --cruft` によって使用されます。呼び出し元はパック名のリストを提供し、どのパックがリポジトリに残るか、およびどのパックが削除されるか (`-` 接頭辞で示される) を示します。cruft パックの内容は、生き残ったパックに含まれていないすべてのオブジェクトで、猶予期間を超過していないもの (下記 `--cruft-expiration` を参照)、または猶予期間を超過しているが、超過していない別のオブジェクトから到達可能なもの、です。

入力がすべての到達可能なオブジェクトを含むパックをリストし（かつ、他のすべてのパックを削除保留としてリストする場合）、対応する cruft パックには、すべての到達不能なオブジェクト（`--cruft-expiration` よりも新しい mtime を持つもの）と、mtime が `--cruft-expiration` よりも古いものの、`--cruft-expiration` よりも新しい mtime を持つ到達不能なオブジェクトから到達可能な到達不能なオブジェクトが含まれます。

`--unpack-unreachable`、`--keep-unreachable`、`--pack-loose-unreachable`、`--stdin-packs`、および `--revs` を意味する他のオプションとは互換性がありません。

--cruft-expiration=<approxidate>

指定された場合、mtime が `<approxidate>` よりも古いオブジェクトは cruft パックから除外されます。指定されない場合 (`--cruft` が与えられた場合)、オブジェクトは除外されません。

--window=<n>
--depth=<n>

これら2つのオプションは、デルタ圧縮を使用してパックに含まれるオブジェクトがどのように保存されるかに影響します。オブジェクトはまず内部的にタイプ、サイズ、オプションで名前によってソートされ、デルタ圧縮がスペースを節約するかどうかを確認するために --window 内の他のオブジェクトと比較されます。--depth は最大デルタ深度を制限します。深度が深すぎると、必要なオブジェクトに到達するためにデルタデータを何度も適用する必要があるため、アンパッカー側のパフォーマンスに影響します。

--window のデフォルト値は 10、--depth は 50 です。最大深度は 4095 です。

--window-memory=<n>

このオプションは `--window` に加えて追加の制限を提供します。ウィンドウサイズは、メモリ内で _<n>_ バイト以上を占有しないように動的に縮小されます。これは、大きなオブジェクトと小さなオブジェクトが混在するリポジトリで、大きなウィンドウでメモリ不足にならないようにしつつ、小さなオブジェクトに対して大きなウィンドウの利点を活用できる場合に役立ちます。サイズには「k」「m」「g」の接尾辞を付けることができます。`--window-memory=0` はメモリ使用量を無制限にします。デフォルトは `pack.windowMemory` 設定変数から取得されます。

--max-pack-size=<n>

異常なシナリオでは、ファイルシステム上で特定のサイズを超えるファイルを作成できない場合があります。このオプションを使用すると、コマンドに対し、出力パックファイルを指定されたサイズを超えない複数の独立したパックファイルに分割するように指示できます。サイズには「k」、「m」、「g」の接尾辞を付けることができます。許可される最小サイズは1 MiBに制限されています。構成変数 `pack.packSizeLimit` が設定されていない限り、デフォルトは無制限です。このオプションは、リポジトリが大きくなり、速度が低下する可能性があることに注意してください。`pack.packSizeLimit` の議論を参照してください。

--honor-pack-keep

このフラグを指定すると、ローカルパックにすでに存在するオブジェクトで .keep ファイルを持つものは、本来パックされるはずであっても無視されます。

--keep-pack=<pack-name>

このフラグを指定すると、指定されたパックに既に存在するオブジェクトは、本来パックされるはずであっても無視されます。`<pack-name>` は、先頭のディレクトリを含まないパックファイル名です (例: `pack-123.pack`)。このオプションは、複数のパックを維持するために複数回指定できます。

--incremental

このフラグを指定すると、パックにすでに存在するオブジェクトは、本来パックされるはずであっても無視されます。

--local

このフラグを指定すると、代替オブジェクトストアから借りてきたオブジェクトは、本来パックされるはずであっても無視されます。

--non-empty

少なくとも1つのオブジェクトが含まれる場合にのみ、パックアーカイブを作成します。

--progress

-q が指定されない限り、標準エラー出力ストリームがターミナルに接続されている場合、デフォルトで進捗状況が報告されます。このフラグは、標準エラー出力ストリームがターミナルに向けられていない場合でも、進捗状況を強制的に表示します。

--all-progress

`--stdout` が指定されている場合、オブジェクトのカウントと圧縮の段階では進捗状況が表示されますが、書き出しの段階では抑制されます。その理由は、出力ストリームが直接別のコマンドにリンクされている場合があり、そのコマンドが受信パックデータを処理する際に独自の進捗状況を表示したい場合があるためです。このフラグは `--progress` と似ていますが、`--stdout` が使用されている場合でも書き出し段階の進捗状況レポートを強制する点が異なります。

--all-progress-implied

これは、進捗状況表示がアクティブ化されるたびに `--all-progress` を暗黙的に有効にするために使用されます。`--all-progress` とは異なり、このフラグ自体は実際の進捗状況表示を強制しません。

-q

このフラグを指定すると、コマンドは標準エラー出力ストリームに進捗状況を報告しません。

--no-reuse-delta

既存のパックを持つリポジトリでパックアーカイブを作成する際、このコマンドは既存のデルタを再利用します。これにより、パックがわずかに最適でなくなる場合があります。このフラグを指定すると、コマンドは既存のデルタを再利用せず、ゼロから計算します。

--no-reuse-object

このフラグを指定すると、コマンドはデルタ化されていないオブジェクトを含む既存のオブジェクトデータを一切再利用せず、すべてを再圧縮することを強制します。これは `--no-reuse-delta` を意味します。これは、パックデータに異なる圧縮レベルを全体的に強制したいという稀なケースでのみ役立ちます。

--compression=<n>

生成されるパック内の新しく圧縮されるデータに適用する圧縮レベルを指定します。指定されていない場合、パック圧縮レベルはまず pack.compression、次に core.compression によって決定され、どちらも設定されていない場合は zlib のデフォルトである -1 になります。ソースに関わらずすべてのデータに統一された圧縮レベルを強制したい場合は、`--no-reuse-object` を追加してください。

--[no-]sparse

`--revs` オプションと組み合わせて使用する場合、パックに含めるオブジェクトを決定するための「スパース」アルゴリズムを切り替えます。このアルゴリズムは、新しいオブジェクトを導入するパスに現れるツリーのみを辿ります。これにより、小さな変更を送信するためのパックを計算する際に、パフォーマンスが大幅に向上する可能性があります。ただし、含まれるコミットに特定の種類の直接的な名前変更が含まれている場合、パックファイルに余分なオブジェクトが追加される可能性があります。このオプションが含まれない場合、デフォルトで `pack.useSparse` の値になりますが、これは特に指定がない限り true です。

--thin

ネットワーク転送を減らすために、送信者と受信者の間の共通オブジェクトを省略して「シンパック」を作成します。このオプションは `--stdout` と組み合わせてのみ意味があります。

注: シンパックは、必要なオブジェクトを省略することでパックアーカイブ形式に違反しており、自己完結型にしない限り Git では使用できません。自己完結型プロパティを復元するには、`git index-pack --fix-thin` ( git-index-pack[1] を参照) を使用してください。

--shallow

シャローリポジトリを持つクライアントに提供されるパックを最適化します。このオプションは、`--thin` と組み合わせることで、速度を犠牲にしてパックを小さくすることができます。

--delta-base-offset

パックアーカイブは、デルタのベースオブジェクトを20バイトのオブジェクト名またはストリーム内のオフセットとして表現できますが、古いバージョンのGitは後者を理解しません。デフォルトでは、_git pack-objects_ は互換性を高めるために前者のみを使用します。このオプションを使用すると、コマンドはコンパクトさのために後者を使用できます。平均的なデルタチェーンの長さに応じて、このオプションは通常、結果のパックファイルを3〜5パーセント縮小します。

注: `git gc` ( git-gc[1] を参照) や `git repack` ( git-repack[1] を参照) のようなポーセリンコマンドは、現代のGitではリポジトリ内のオブジェクトをパックファイルに入れる際にデフォルトでこのオプションを渡します。`git bundle` ( git-bundle[1] を参照) もバンドルを作成する際に同様に渡します。

--threads=<n>

最適なデルタマッチを検索する際に生成するスレッド数を指定します。これには pack-objects が pthreads と共にコンパイルされている必要があり、そうでない場合、このオプションは警告とともに無視されます。これはマルチプロセッサマシンでのパッキング時間を短縮することを意図しています。ただし、デルタ検索ウィンドウに必要なメモリ量はスレッド数で乗算されます。0 を指定すると、Git は CPU の数を自動検出し、それに応じてスレッド数を設定します。

--index-version=<version>[,<offset>]

これはテストスイートでのみ使用することを意図しています。生成されるパックインデックスのバージョンを強制したり、指定されたオフセットより上位に位置するオブジェクトに64ビットインデックスエントリを強制したりすることができます。

--keep-true-parents

このオプションを指定すると、グラフトによって隠されている親もパックされます。

--filter=<filter-spec>

結果のパックファイルから特定のオブジェクト (通常はブロブ) を省略します。有効な `<filter-spec>` 形式については、git-rev-list[1] を参照してください。

--no-filter

以前の `--filter=` 引数をすべて無効にします。

--missing=<missing-action>

将来の「部分クローン」開発を支援するためのデバッグオプションです。このオプションは、欠落オブジェクトの処理方法を指定します。

形式 _--missing=error_ は、欠落オブジェクトに遭遇した場合に pack-objects がエラーで停止するよう要求します。リポジトリが部分クローンの場合、欠落と宣言する前に欠落オブジェクトをフェッチする試みが行われます。これがデフォルトのアクションです。

形式 _--missing=allow-any_ は、欠落オブジェクトに遭遇した場合でもオブジェクトの走査を続行させます。欠落オブジェクトのフェッチは行われません。欠落オブジェクトは結果から黙って省略されます。

形式 _--missing=allow-promisor_ は _allow-any_ と似ていますが、EXPECTED なプロミサー欠落オブジェクトに対してのみオブジェクトの走査を続行させます。欠落オブジェクトのフェッチは行われません。予期せぬ欠落オブジェクトはエラーを発生させます。

--exclude-promisor-objects

プロミサーリモートに存在することが知られているオブジェクトを省略します。(このオプションは、ローカルで作成されたオブジェクトのみに作用することを目的としています。これにより、リパックする際に、ローカルで作成されたオブジェクト [.promisorなし] とプロミサーリモートからのオブジェクト [.promisorあり] の区別を維持できます。) これは部分クローンで使用されます。

--keep-unreachable

`--unpacked=` オプションで指定されたパック内の参照から到達不能なオブジェクトは、*.keep ファイルでマークされていない到達可能なオブジェクトに加えて、結果のパックに追加されます。これは `--revs` を意味します。

--pack-loose-unreachable

到達不能なルーズオブジェクトをパックし（そしてそのルーズな対応物を削除し）ます。これは `--revs` を意味します。

--unpack-unreachable

到達不能なオブジェクトをルーズな形式で保持します。これは `--revs` を意味します。

--delta-islands

「アイランド」に基づいてデルタマッチを制限します。以下の「デルタアイランド」を参照してください。

--name-hash-version=<n>

デルタ圧縮を実行する際、Git はオブジェクトへのパスを使用してヒューリスティックに基づいて類似している可能性のあるオブジェクトをグループ化します。正確なパスの一致によってオブジェクトをグループ化することは、多数のバージョンを持つパスにとって良いことですが、異なるフルパス間でデルタペアを見つけることには利点があります。Git は、オブジェクトをタイプ別、次にパスの「名前ハッシュ」別、そしてサイズ別に収集し、うまく圧縮できるオブジェクトをグループ化することを期待します。

デフォルトの名前ハッシュバージョンは `1` で、パスの末尾のバイトをハッシュ関数への最大寄与として考慮することで、ハッシュの局所性を優先します。このバージョンは、短いパスを区別し、ディレクトリ間の名前変更を見つけるのに優れています。ただし、ハッシュ関数は主にパスの末尾16バイトに依存します。もしリポジトリ内に末尾16バイトが同じで親ディレクトリのみが異なるパスが多数ある場合、この名前ハッシュは衝突を多数引き起こし、結果が悪くなる可能性があります。現時点では、`--write-bitmap-index` を使用して到達可能性ビットマップファイルを書き込む際にはこのバージョンが必要です。

名前ハッシュバージョン `2` は、バージョン `1` と同様の局所性機能を持ちますが、各パスコンポーネントを個別に考慮し、ハッシュをシフトして重ね合わせます。これにより、パスの最終バイトが引き続き優先されますが、親ディレクトリ名を使用してハッシュの下位ビットに「ソルト」も加えます。この方法により、バージョン `1` の局所性の利点の一部を享受しつつ、多くの異なるディレクトリに同様の名前のファイルが出現することによる衝突の大部分を解消できます。現時点では、`--write-bitmap-index` を使用して到達可能性ビットマップファイルを書き込む際にはこのバージョンは許可されておらず、自動的にバージョン `1` に変更されます。

デルタアイランド

可能であれば、`pack-objects` は、既存のオンディスクデルタを再利用して、その場で新しいデルタを検索する必要がないようにします。これはフェッチを提供する上で重要な最適化であり、サーバーがほとんどのオブジェクトをまったく膨張させることなく、バイトをディスクから直接送信できることを意味します。この最適化は、オブジェクトが受信者が持っていない (かつ、まだ送信していない) ベースに対するデルタとして格納されている場合には機能しません。その場合、サーバーはデルタを「破壊」し、新しいデルタを見つける必要があり、これは高い CPU コストがかかります。したがって、オンディスクデルタ関係にあるオブジェクトのセットが、クライアントがフェッチするであろうものと一致することがパフォーマンスにとって重要です。

通常のリポジトリでは、これは自動的に機能する傾向があります。オブジェクトはほとんどがブランチとタグから到達可能であり、それがクライアントがフェッチするものです。サーバーで見つかるデルタは、クライアントが持っている、または持つであろうオブジェクト間にある可能性が高いです。

しかし、一部のリポジトリ設定では、関連するが分離された複数の参照チップグループがあり、クライアントがそれらのグループを独立してフェッチする傾向がある場合があります。たとえば、単一の共有オブジェクトストアでリポジトリのいくつかの「フォーク」をホストし、`GIT_NAMESPACE` または代替メカニズムを使用してクライアントがそれらを独立したリポジトリとして表示できるようにしていると想像してください。単純なリパックでは、オブジェクトの最適なデルタが別のフォークにのみ見つかるベースに対するものであると判断される場合があります。しかし、クライアントがフェッチする際にはベースオブジェクトを持たず、その場で新しいデルタを見つける必要があります。

`refs/heads/` や `refs/tags/` の外側に、関連するオブジェクトを指す多くの参照 (例: 一部のホスティングプロバイダーが使用する `refs/pull` や `refs/changes`) がある場合も、同様の状況が発生する可能性があります。デフォルトでは、クライアントはヘッドとタグのみをフェッチし、他のグループにのみ見つかるオブジェクトに対するデルタはそのまま送信できません。

デルタアイランドは、参照を異なる「アイランド」にグループ化できるようにすることで、この問題を解決します。Pack-objects は、どのアイランドからどのオブジェクトに到達可能かを計算し、オブジェクト `A` のすべてのアイランドに存在しないベースに対するデルタの作成を拒否します。これにより、パックはわずかに大きくなりますが (デルタの機会をいくつか失うため)、1つのアイランドのフェッチがアイランド境界を越えることによってその場でデルタを再計算する必要がないことを保証します。

デルタアイランドでリパックすると、デルタウィンドウは設定で禁止されている候補で詰まってしまう傾向があります。大きな --window でリパックすると役立ちます (そして、内容の計算を行う前にアイランドに基づいて一部のオブジェクトペアを拒否できるため、そうでなければかかる時間ほどかかりません)。

アイランドは `pack.island` オプションによって設定され、複数回指定できます。各値は、参照名に一致する左端がアンカーされた正規表現です。例：

[pack]
island = refs/heads/
island = refs/tags/

ヘッドとタグを1つのアイランドに配置します（その名前は空文字列です。命名に関する詳細は以下を参照）。これらの正規表現に一致しない参照（例：`refs/pull/123`）はどのアイランドにも属しません。`refs/pull/` からのみ（ヘッドやタグからは到達できない）到達可能なオブジェクトは、`refs/heads/` のベースとして使用される候補ではありません。

参照は、その「名前」に基づいてアイランドにグループ化され、同じ名前を生成する2つの正規表現は同じアイランドに属するとみなされます。名前は、正規表現からキャプチャグループを抽出し、それらを `-` (ダッシュ) で連結して計算されます。（キャプチャグループがない場合、上記例のように名前は空文字列です。）これにより、任意の数のアイランドを作成できます。ただし、そのようなキャプチャグループは最大14個までしかサポートされていません。

たとえば、各フォークの参照を `refs/virtual/ID` に保存し、`ID` が数値識別子であると想像してください。その場合、以下のように設定できます。

[pack]
island = refs/virtual/([0-9]+)/heads/
island = refs/virtual/([0-9]+)/tags/
island = refs/virtual/([0-9]+)/(pull)/

これは、各フォークのヘッドとタグを独自のアイランド（「1234」などと命名）に配置し、各フォークのプル参照を独自の「1234-pull」に配置します。

各正規表現について、「最後のものが勝つ」という順序付け（これにより、リポジトリ固有の設定がユーザー全体の設定に優先されるなど）を使用して、単一のアイランドを選択することに注意してください。

設定

様々な設定変数がパッキングに影響を与えます。 git-config[1] を参照してください（「pack」と「delta」で検索してください）。

特に、デルタ圧縮は、`core.bigFileThreshold` 設定変数よりも大きなオブジェクト、および `delta` 属性が false に設定されているファイルには使用されません。

関連項目

git-rev-list[1] git-repack[1] git-prune-packed[1]

Git

git[1] スイートの一部

scroll-to-top