Re: [PATCH 5/5] serve: add support for a git_config() callback

[Jeff King <peff@peff.net>]

On Wed, Jun 16, 2021 at 04:16:21PM +0200, Ævar Arnfjörð Bjarmason wrote:

> Since the introduction of serve.c we've added git_config() callbacks
> and other config reading for capabilities in the following commits:
> 
> - e20b4192a37 (upload-pack: support hidden refs with protocol v2, 2018-12-18)
> - 59e1205d167 (ls-refs: report unborn targets of symrefs, 2021-02-05)
> - 6b5b6e422ee (serve: advertise session ID in v2 capabilities, 2020-11-11)
> 
> This code can be simplified by simply adding support to serve.c itself
> for reading config at the right time before the capability is
> called. In particular the ensure_config_read() function being gone
> makes this whole thing much simpler.
> 
> A behavior change here is that we're eagerly doing the configuration
> for all our capabilities regardless of which one we end up serving,
> whereas before we'd defer it until the point where we were processing
> the specific command.

Hmm. I like simplifying things, but what's the plan for when we have a
v2 receive-pack? We'll need different config based on whether we're
serving a fetch or a push.

While working on e20b4192a37, I had originally proposed patches that
would pass that context into the serve mechanism (based on whether we
were called by upload-pack or receive-pack). But the review there
indicated that v2 receive-pack would probably involve an extra
capability argument passed by the client to ls-refs.

So we'd eventually need to parse config _after_ we've received the
actual ls-refs command. To be clear, this patch isn't breaking anything
now. But I think it's painting us into a corner that we'll regret later.

Of course there are ways around this. E.g., we could read config for
both operations ahead of time, and then decide which to use later. But
that definitely isn't how it works now, and we'd have to refactor the
whole ref_is_hidden() system to fix that. Definitely do-able, but given
the relatively limited upside of this patch, I'm not sure if it's worth
it.

I'd also note that this patch doesn't touch upload_pack_v2() at all,
which also reads config. That one is extra-weird because it reads the
config fresh for every round of interaction with the client, and then
cleans it up. Which led to fixes like the one in 08450ef791
(upload-pack: clear filter_options for each v2 fetch command,
2020-05-08).

Doing a single config read would probably make that simpler. But the
config setup is shared between the v0 and v2 functions, so extracting it
into serve() would potentially be awkward.

> In particular the ensure_config_read() function being gone
> makes this whole thing much simpler.

I do agree this is awkward. The two calls for that function seem to come
from the "should we advertise ls-refs" and "actually do ls-refs"
functions. Should we be able to assume that the former ran if we are in
the latter? I'm not sure if that's true or not (i.e., because it's
rare but possible for a client to make two separate HTTP requests, one
to discover our v2 capabilities and another to actually issue ls-refs).

-Peff