Oh, so here you address my previous comments. I'd propose to either squash those two commits or to not introduce "acceptFromServer" in the preceding commit in the first place. On Tue, Sep 10, 2024 at 06:30:00PM +0200, Christian Couder wrote: > diff --git a/Documentation/config/promisor.txt b/Documentation/config/promisor.txt > index 9cbfe3e59e..d1364bc018 100644 > --- a/Documentation/config/promisor.txt > +++ b/Documentation/config/promisor.txt > @@ -12,9 +12,19 @@ promisor.advertise:: > promisor.acceptFromServer:: > If set to "all", a client will accept all the promisor remotes > a server might advertise using the "promisor-remote" > - capability. Default is "none", which means no promisor remote > - advertised by a server will be accepted. By accepting a > - promisor remote, the client agrees that the server might omit > - objects that are lazily fetchable from this promisor remote > - from its responses to "fetch" and "clone" requests from the > - client. See linkgit:gitprotocol-v2[5]. > + capability. If set to "knownName" the client will accept > + promisor remotes which are already configured on the client > + and have the same name as those advertised by the client. Wait, does this mean that a server can start advertising new promisor remotes at any point in time and we'd backfill them on the client whenever we execute git-fetch(1)? That sounds fishy to me -- I wouldn't want anything to touch my configuration after I have created the repo unless I explicitly tell it to. If so, how does this handle the case where I manually added a remote that by accident (or malicious intent of the server) that matches one of the newly-advertised promisor remotes? This goes back to one of my previous comments, where I said that it's likely not a good idea to let the remote dictate names of our remotes in the first place. If not, where do the known names come from? Patrick
