クライアントが不要なオブジェクトをサーバーに記述するメカニズム。

サーバーがそのような不要なオブジェクトをクライアントに送信されるパックファイルから除外するメカニズム。

クライアントが不足しているオブジェクト（以前にサーバーによって除外されたもの）を適切に処理するメカニズム。

クライアントが必要に応じて不足しているオブジェクトを補充するメカニズム。

新しいパックプロトコル機能「filter」がフェッチパックとアップロードパックのネゴシエーションに追加されました。

クライアントは「filter-spec」をクローンとフェッチに渡し、それがサーバーに渡されてパックファイル構築中のフィルタリングを要求します。

サーバー側では、pack-objects は、クライアント用の「フィルタリングされた」パックファイルを作成する際に、要求された filter-spec を適用します。

クライアントでは、これらの不完全なパックファイルは「プロミサーパックファイル」としてマークされ、さまざまなコマンドによって異なる方法で扱われます。

クライアントでは、古いバージョンの Git が、処理できないオブジェクトの不足によって操作中に失敗するのを防ぐために、リポジトリ拡張がローカル設定に追加されます。 git-config[1] の extensions.partialClone を参照してください。

オブジェクトは、部分クローンまたはフェッチによって不足している場合、あるいはリポジトリの破損によって不足している場合があります。これらのケースを区別するために、ローカルリポジトリは、プロミサーリモートから取得したそのようなフィルタリングされたパックファイルを「プロミサーパックファイル」として特別に示します。

ローカルリポジトリは、「プロミサーオブジェクト」を、プロミサーリモートが持っていると約束した（能力の限り）オブジェクトであると見なします。これは、ローカルリポジトリがそのオブジェクトをプロミサーパックファイルのいずれかに持っているか、または別のプロミサーオブジェクトがそれを参照しているためです。

現在のほとんどの Git コードは、参照されるすべてのオブジェクトがローカルに存在することを期待しており、すべてのコマンドに最初にドライランを実行させることを強制したくないため、Git がプロミサーリモートから不足しているオブジェクトを動的にフェッチしようとすることを可能にするフォールバックメカニズムが追加されました。

checkout (および unpack-trees を使用する他のすべてのコマンド) は、必要な欠落ブロブをすべて単一のバッチで一括プリフェッチするように教えられました。

rev-list は、欠落しているオブジェクトを出力するように教えられました。

fsck は、プロミサーオブジェクトを完全に認識するように更新されました。

GC の repack は、プロミサーパックファイルには一切触れず、他のオブジェクトのみをリパックするように更新されました。

グローバル変数 "fetch_if_missing" は、オブジェクト検索が欠落オブジェクトを動的にフェッチしようとするか、エラーを報告するかを制御するために使用されます。

オブジェクトのフェッチは、「git fetch」サブプロセスを呼び出すことによって行われます。

ローカルリポジトリは、要求されたすべてのオブジェクトのハッシュを含む要求を送信し、パックファイルのネゴシエーションは実行しません。その後、パックファイルを受信します。

既存のフェッチメカニズムを再利用しているため、現在、フェッチは、要求されたオブジェクトによって参照されるすべてのオブジェクトをフェッチします。これらは必ずしも必要ではありません。

--refetch を使用したフェッチは、リモートから完全な新しいフィルタリングされたパックファイルを要求します。これは、不足しているオブジェクトを動的にフェッチすることなくフィルターを変更するために使用できます。

extensions.partialClone = <name>

remote.<name>.promisor = true

remote.<name>.partialCloneFilter = ...

プロミサーリモートが試行される順序を、設定ファイルに現れる順序以外の方法で指定することはできません。

特定のオブジェクトのみをプロミサーリモートにプッシュすることはできません。

動的なオブジェクトのフェッチは、不足しているオブジェクトに対してのみプロミサーリモートに問い合わせます。プロミサーリモートはリポジトリの完全なビューを持ち、そのようなすべての要求を満たすことができると仮定しています。

Repack は基本的にプロミサーと非プロミサーのパックファイルを 2 つの異なるパーティションとして扱い、それらを混合しません。

ほとんどのアルゴリズムは、欠落しているオブジェクトに遭遇し、作業を続行する前にそれを解決する必要があるため、動的なオブジェクトのフェッチは各アイテムに対して一度 fetch-pack を呼び出します。多くのオブジェクトが必要な場合、これはかなりのオーバーヘッド（および複数の認証要求）を引き起こす可能性があります。

動的なオブジェクトのフェッチは現在、既存のパックプロトコル V0 を使用しているため、各オブジェクトは fetch-pack を介して要求されます。接続が確立されると、サーバーは完全な info/refs セットを送信します。参照の数が多い場合、これはかなりのオーバーヘッドを引き起こす可能性があります。

プロミサーリモートが試行される順序を指定する方法を改善する。

プロミサーリモートへのプッシュを許可する。

パックファイルビットマップ（存在する場合）を利用するために、パス名ベースではないフィルターを許可する。これは初期実装時の単なる見落としでした。

[5,6] で提案されているように、プロセス起動とオーバーヘッドコストを削減するために、一連のオブジェクトを動的にフェッチする長時間実行プロセスを使用することを調査します。

不足しているオブジェクトを動的にフェッチするためにサーバーとの接続ごとに info/refs のブロードキャストを回避するために、パックプロトコル V2 の必要性を調査します。

ゆるいプロミサーオブジェクトを処理する必要性を調査する。

「ブロブのオンデマンド読み込み」という話題が出るたびに、誰かがサーバーが「推測」して、要求されたオブジェクトに関連する可能性のある追加のオブジェクトを送信することを許可すべきだと提案するようです。