Packfile URIs

サーバーは packfile-uris の機能を宣伝(advertise)します。

クライアントがサポートするプロトコル(HTTPSなど)を packfile-uris の引数で通信する場合、サーバーは packfile セクションの直前(wanted-refs の直後に送信された場合）に packfile-uris セクションを送信する場合があります。指定されたプロトコルのいずれかのURIを含みます。 URIは、クライアントがサポートすると宣言した機能(ofs-deltaやthin-packなど)のみを使用するパックファイルを指します。 このセクションのドキュメントについては、 gitprotocol-v2(5) を参照してください。

次に、クライアントは、接続チェックを実行する前に、(応答の packfile セクションで指定されたpackfileをダウンロードしてインデックスを作成することに加えて)指定されたすべてのURIをダウンロードしてインデックスを作成する必要があります。

サーバーは、 packfile-uris を広告し、クライアントが packfile-uris を送信し、 packfile-uris セクションを送信しないようにすることで、提案されたプロトコルと簡単に互換性を持たせることができます。 ただし、少なくともクライアントをテストできるように、 Minimum Viable Product にある種の重要な実装を含める必要があります。

これは実装です。実験的なマークが付けられた機能で、サーバーを1つ以上の uploadpack.blobPackfileUri= <object-hash> <pack-hash> <uri> エントリで構成できます。 送信されるオブジェクトのリストが組み立てられるたびに、そのようなすべてのブロブが除外され、URIに置き換えられます。 以下の「Future work」で説明するように、サーバーは将来、プロトコルを変更せずに他のオブジェクトの除外をサポートするように進化する可能性があります(または、他のオブジェクトの除外をサポートするサーバーの他の実装を作成できます)。したがって、クライアントはパックファイルがダウンロードされることを期待しないでください。 このように、単一のブロブのみが含まれます。

クライアントには、エンドユーザーが使用するプロトコルを決定する構成変数 fetch.uriprotocols があります。 デフォルトでは、これは空(empty)です。

クライアントが指定されたURIをダウンロードするときは、 packfile セクションのpackfileの場合と同様に、それらを「keep」ファイルとともに保存する必要があります。 これらの追加の「keep」ファイルは、参照が更新された後にのみ削除できます。これは、「packfile」セクションのpackfileの「keep」ファイルと同じです。

作業の分割(初期フェッチ + 追加のURI)により、中断されたクローン作業を再開するための便利なポイントが導入されます。このような再開は、Minimum Viable Productの後で実行できます(「Future work」参照)。

プロトコル設計により、プロトコルを変更することなくサーバーとクライアントをある程度進化させることができるため、MVPを形成するためにここに含まれるのは小さな範囲の設計のみです。 たとえば、以下のことができます:

プロトコルの変更を必要とする可能性のある機能がいくつかあります: