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

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

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

クライアントが必要に応じて不足しているオブジェクトをバックフィルするためのメカニズム。

fetch-pack および upload-pack のネゴシエーションに、新しいパックプロトコル機能「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 を1回呼び出します。多くのオブジェクトが必要な場合、これにより大きなオーバーヘッドと複数の認証要求が発生する可能性があります。

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

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

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

パス名に基づかないフィルターが（存在する場合）パックファイルビットマップを利用できるようにします。これは、最初の実装時の単なる見落としでした。

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

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

ルーズなプロミサーオブジェクトを処理する必要性を調査します。

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