SYNOPSIS

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] < <object-list>

DESCRIPTION

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

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

パックされたアーカイブ形式(.pack)は、自己完結型であるように設計されているため、追加の情報なしで解凍できるように作られています。そのため、デルタが依存している各オブジェクトは、パック内に存在していなければなりません。

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

git unpack-objects コマンドは、パックされたアーカイブを読み取り、パックに含まれるオブジェクトを「1ファイル1オブジェクト」形式に展開できます。これは通常、ピアによる効率的なネットワーク転送のためにパックがオンザフライで作成されるときに、smart-pullコマンドによって実行されます。

OPTIONS

base-name

ファイルのペア(.packと.idx)に書き込み、そして、 <base-name> を使用して、作成されたファイルの名前を決定します。このオプションを使用すると、ペアの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/ の下のすべてのrefが含まれるように指定してあるかのように振る舞います。

--include-tag

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

--stdin-packs

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

互換性のある --unpacked を除いて、 --revs または、 --revs を含むオプション(--all など)とは互換性がありません。

--cruft

到達不能なオブジェクトを、 .mtimes ファイルの存在によって示される別の「クラフト・パック」にパックします。 通常は git repack --cruft で使用されます。 呼び出し元はパック名のリストを提供し、 リポジトリに残すパックと、 削除するパック(接頭辞 - )を指定します。 クラフト・パックの内容は、 既存パックに含まれていない全てのオブジェクトで、 猶予期間(下記 --cruft-expiration 参照)を過ぎて無いもの、 または、 自身は猶予期間を過ぎているものの、 まだ期限が切れていない他のオブジェクトから到達可能なものです。

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

--unpack-unreachable や --keep-unreachable や --pack-loose-unreachable や --stdin-packs と、--revs を暗示するその他のオプションとは互換性がありません。

--cruft-expiration=<approxidate>

指定されている場合、 mtime が <approxidate> よりも古いオブジェクトはクラフト・パック(cruft pack)から削除されます。 指定されていない(そして --cruft が指定されている)場合、オブジェクトは削除されません。

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

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

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

--window-memory=<n>

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

--max-pack-size=<n>

めったにないシナリオですが、ファイルシステム上に特定のサイズより大きいファイルを作成できない場合があります。このオプションを使用して、出力パックファイルをそれぞれ指定されたサイズ以下の複数の独立したパックファイルに分割するようにコマンドに指示できます。 サイズには、「k」または「m」または「g」の接尾辞を付けることができます。許可される最小サイズは1MiBに制限されています。 構成変数 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 オプションと組み合わせた場合、「スパース」(sparse)アルゴリズムを切り替えて、パックに含めるオブジェクトを決定します。このアルゴリズムは、新しいオブジェクトを導入するパスに現れるツリーのみをウォークします。これは、小さな変更を送信するためのパックを計算するときに、パフォーマンスに大きなメリットをもたらす可能性があります。ただし、含まれているコミットに特定の種類の直接名前変更(direct renames)含まれている場合は、パックファイルに追加のオブジェクトが追加される可能性があります。このオプションが含まれていない場合、デフォルトで pack.useSparse の値になります。 pack.useSparse の値は、特に指定されていない限りtrueです。

--thin

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

注意: 薄いパック(thin pack)は、 必要なオブジェクトを省略するという理由により、パックされたアーカイブ形式に違反するため、 自己完結型にしないと Git で使用できません。 自己完結型のプロパティを復元するには git index-pack --fix-thin (git-index-pack(1) を参照)使用してください。

--shallow

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

--delta-base-offset

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

注意: 最新のGitでは、 git gc (git-gc(1) 参照)や git repack (git-repack(1) 参照)などの磁器コマンドは、あなたのリポジトリ内のファイルをパックファイルに入れるときに、デフォルトでこのオプションを渡します。バンドルを作成する git bundle (git-bundle(1) 参照)も同様です。

--threads=<n>

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

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

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

--keep-true-parents

このオプションを使用すると、 grafts によって隠されている親も、 それでもなおパックされます。

--filter=<filter-spec>

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

--no-filter

以前の任意の --filter= 引数をオフにします。

--missing=<missing-action>

将来の「partial clone」(部分クローン)開発に役立つデバッグオプション。このオプションは、欠落しているオブジェクトの処理方法を指定します。

--missing=error は、欠落しているオブジェクトが検出された場合に、pack-objectsがエラーで停止することを要求します。リポジトリが部分クローン(partial clone)の場合は、欠落していると言う前に、欠落しているオブジェクトをフェッチしようとします。 --missing=error がデフォルトの操作です。

--missing=allow-any は、欠落しているオブジェクトが検出された場合でも、オブジェクトの走査(object traversal)を続行できます。欠落しているオブジェクトのフェッチは発生しません。欠落しているオブジェクトは、結果から警告無しに黙って省略されます。

--missing=allow-promisor は allow-any に似ていますが、オブジェクトの走査は、「予想される」promisorが欠落しているオブジェクトに対してのみ続行できます。欠落しているオブジェクトのフェッチは発生しません。予期しないオブジェクトの欠落により、エラーが発生します。

--exclude-promisor-objects

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

--keep-unreachable

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

--pack-loose-unreachable

到達不能な緩いオブジェクト(loose objects)をパックします(そしてそれらの緩いオブジェクトを削除します)。 これは --revs の指定を含んでいます。

--unpack-unreachable

到達不能なオブジェクトは緩い(loose)オブジェクト形式のままにしてください。これは --revs の指定を含んでいます。

--delta-islands

「islands」に基づいてデルタのマッチを制限します。 以下の DELTA ISLANDS を参照してください。

DELTA ISLANDS

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

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

ただし、一部のリポジトリ設定では、いくつかの関連しているが別個のref先端のグループがあり、クライアントはそれらのグループを個別にフェッチする傾向があります。 たとえば、単一の共有オブジェクトストアでリポジトリの複数の「フォーク」をホストし、クライアントがそれらを GIT_NAMESPACE を介して個別のリポジトリとして、または代替メカニズムを使用して個別のリポジトリとして表示できるようにする場合を考えてみます。素朴な再パックでは、オブジェクトの最適なデルタが、別のフォークでのみ検出されるベースに対してのものであることがわかる場合があります。ただし、クライアントがフェッチするとき、クライアントにはベースオブジェクトがないため、その場で新しいデルタを見つける必要があります。

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

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

デルタ島(delta islands)で再パックする場合、デルタ窓は、構成によって禁止されている候補で詰まる傾向があります。大きな --window で再梱包することが助けになります(コンテンツに対して計算を行う前に、島に基づいて一部のオブジェクトペアを拒否できるため、他の方法ほど長くはかかりません)。

島は、複数回指定できる pack.island オプションを介して構成されます。各値は、refnames に一致する左アンカーの正規表現(left-anchored regular expressions)です。 例えば:

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

ヘッドとタグを島に配置します(名前は空の文字列です。名前の詳細については、以下を参照してください)。 これらの正規表現に一致しない参照(例: refs/pull/123)は、どの島にもありません。 したがって、 refs/pull/ からのみ到達可能(ヘッドやタグは不可)のオブジェクトは、 refs/heads/ のベースとして使用される候補にはなりません。

参照は「名前」に基づいて島にグループ化され、同じ名前を生成する2つの正規表現は同じ島にあると見なされます。名前は、正規表現で間に「-」ダッシュがあるキャプチャグループを連結することにより、正規表現から計算されます(訳注:[0-9]+ の部分)。(キャプチャグループがない場合、上記の例のように、名前は空の文字列になります。) これにより、任意の数の島を作成できます。 ただし、このようなキャプチャグループは最大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” などの名前)に配置され、それぞれのプルrefsが独自の "1234-pull" になります。

注意: 「最後の1つが勝つ」順序を使用して、正規表現ごとに1つの島を選択することに注意してください(これにより、リポジトリ固有の構成がユーザー全体の構成よりも優先されます)。

CONFIGURATION

さまざまな構成変数がパッキングに影響します。 git-config(1) を参照してください( pack および delta を検索してください)。

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

SEE ALSO

git-rev-list(1) git-repack(1) git-prune-packed(1)

GIT

Part of the git(1) suite