On Wed, May 7, 2025 at 1:14 PM Patrick Steinhardt <ps@xxxxxx> wrote: > > On Tue, Apr 29, 2025 at 04:52:43PM +0200, Christian Couder wrote: > > diff --git a/Documentation/config/promisor.adoc b/Documentation/config/promisor.adoc > > index 71311b70c8..4147d2cf44 100644 > > --- a/Documentation/config/promisor.adoc > > +++ b/Documentation/config/promisor.adoc > > @@ -46,3 +46,28 @@ promisor.acceptFromServer:: > > lazily fetchable from this promisor remote from its responses > > to "fetch" and "clone" requests from the client. Name and URL > > comparisons are case sensitive. See linkgit:gitprotocol-v2[5]. > > + > > +promisor.checkFields:: > > + A comma or space separated list of additional remote related > > + fields that a client will check before accepting a promisor > > + remote. Currently, only the "partialCloneFilter" and "token" > > + fields are supported. > > ++ > > +When a field is part of this list and a corresponding > > +"remote.foo.<field>" config variable is set locally for remote "foo", > > +then the value of this config variable will be checked against the > > +value of the same field passed by the server for the remote "foo". The > > +remote "foo" will be rejected if the values don't match. > > ++ > > +For the "partialCloneFilter" field, this allows the client to ensure > > +that the server's filter matches what it expects locally, preventing > > +inconsistencies in filtering behavior. For the "token" field, this can > > +be used to verify that authentication credentials match expected > > +values. > > ++ > > +The fields should be passed by the server through the > > +"promisor-remote" capability by using the `promisor.sendFields` config > > +variable. The fields will be checked only if the > > +`promisor.acceptFromServer` config variable is not set to "None". If > > +set to "None", this config variable will have no effect. See > > +linkgit:gitprotocol-v2[5]. > > One thought that came to my mind is that inevitably, users will > eventually want to specify different conditions and combinations. E.g. > "accept a promisor remote if it's announced by GitLab and if the partial > filter strips blobs, but not if it requires additional authentication". > I don't think that "checkFields" would be able to implement such a use > case. > > What is the vision where we want to end up here? Should we maybe provide > some more flexibility now already so that we don't have to retrofit such > a mechanism in the future? I'd prefer to wait until some concrete cases appear. It's possible that the current very simple mechanism will be enough for some time, or it's possible that some users will come soon with a complex use case where it might be necessary to have a hook or some kind of external script called. In those cases it would be sad if we added some flexibility in advance but it appears to be too much or not enough.
