Christian Couder <christian.couder@xxxxxxxxx> writes: > The "promisor-remote" capability can only be used to pass the names > and URLs of the promisor remotes from the server to the client. After > that the client can use this information to decide if it accepts the > remotes or not. > > It would be nice if the server could pass more fields about its > remotes and if the client could use that additional information to > decide about the remotes by comparing it with its local information > about the remotes. > > This patch series implements this by adding the "promisor.sendFields" > on the server side and the "promisor.checkFields" on the client side. > > For example, if "promisor.sendFields" is set to "partialCloneFilter", > and the server has the remote "foo" configured like this: > > [remote "foo"] > url = file:///tmp/foo.git > partialCloneFilter = blob:none > > then "name=foo,url=file:///tmp/foo.git,partialCloneFilter=blob:none" > will be sent by the server for this remote. > > All the information passed through the "promisor-remote" capability is > still only used to decide if the remotes are accepted or not. The > client doesn't store it and doesn't use it for any other purpose. > > Note that the filter mechanism already exists for a long time and this > series doesn't change how it works. For example, it has already been > possible for a long time to have different repos using the same > promisor remote with different filters. See the existing partial clone > documentation (like "Documentation/technical/partial-clone.adoc") for > more information on partial clone. > > The fields that can be passed are limited to "partialCloneFilter" and > "token". > > On the technical side, we get rid of 'struct strvec' and we use > 'struct promisor_info' to store the data and 'struct string_list' to > store the 'struct promisor_info' instances instead. This matches the > latest suggestion from Junio. > > This work is part of the "LOP" effort documented in: > > Documentation/technical/large-object-promisors.adoc > > See that doc for more information on the broader context. > I've left some small nits, but mostly this version looks good to me. I don't specifically see a need for re-roll, but will leave it up to you! [snip] Thanks, - Karthik
Attachment:
signature.asc
Description: PGP signature
