Jonathan Tan <jonathantanmy@xxxxxxxxxx> writes: > +The server advertises the `packfile-uris` capability. > + > +If the client then communicates which protocols (HTTPS, etc.) it supports with > +a `packfile-uris` argument, the server MAY send a `packfile-uris` section > +directly before the `packfile` section (right after `wanted-refs` if it is > +sent) containing URIs of any of the given protocols. The URIs point to > +packfiles that use only features that the client has declared that it supports > +(e.g. ofs-delta and thin-pack). See protocol-v2.txt for the documentation of > +this section. Even if we have some pre-packaged packfiles, if the requestor lacks some feature (by the way, shouldn't we consistently use "capability" instead of "feature" to call things like "ofs-delta"?) to be able to understand them, we would already know that fact (i.e. the lack of capability on the other side) by the time we have to decide if we can give packfile-uris section. OK, this makes sense. > +Clients should then download and index all the given URIs (in addition to > +downloading and indexing the packfile given in the `packfile` section of the > +response) before performing the connectivity check. Looking good. Is there other requirement on the packfile that can be retrieved with the URI listed in the packfile-uris section? It would be clear that it must, together with the contents in the dynamic 'packfile' section, give fully connected set of objects to the other side that has the object it claimed to have. But are we allowed to include extra/unasked-for objects in such a packfile? Or is it better to leave it unspecified? Thanks.
