Re: Exec upload-pack on remote with what parameters to get direntries.

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Aug 31, 2021, 14:23 UTC
Message-ID: <87sfypwuwx.fsf@evledraar.gmail.com>
In-Reply-To: <xmqq4kb639xt.fsf@gitster.g>

On Mon, Aug 30 2021, Junio C Hamano wrote:

Show 18 quoted lines

> Jeff King <peff@peff.net> writes:
>
>> Yes. At GitHub we actually have a custom endpoint which hooks up
>> "cat-file --batch" with a format of the client's choosing. That's what
>> (indirectly) feeds things like raw.github.com.
>>
>> I've been tempted to send it upstream, but it's pretty ugly, and does
>> give the client a lot of power (for now, the placeholders you can use
>> with cat-file are not that powerful, but if we start to unify with
>> ref-filter, etc, then we run into situations like we had with
>> %(describe) recently). Likewise, the v2 object-info endpoint _could_
>> accept arbitrary format strings (it's the same idea, just with
>> --batch-check instead of --batch).
>
> Yeah, the object-info actually was from folks who are interested in
> doing something similar, and it would be nice if we can share the
> protocol endpoint that is more suitable for interactive tree and
> history traversal to help those who want to do virtual filesystem.

While this is all clever, I think this discussion really suggests that the first thing we should do is make the relatively recent "object-info" protocol verb not a default part of the supported v2 protocol we ship in git.git.

I.e. someone setting up a git server probably isn't going to suspect that one day their server load is going to go up by some big % because some developer somewhere is using a local IDE whose every file click on a directory is a new remote server request (i.e. the case where "object-info"'s functionality is expanded like this).

I found myself wondering this when reading serve.c the other day, i.e. why we have "always_advertise" for object-info, but it seemed innocuous enough given how it's described in a2ba162cda2 (object-info: support for retrieving object info, 2021-04-20).

But just as a general thing, while I'm very much in favor of git growing *optional* support for more server<->client cooperation and CPU offloading, even things like "git grep" or "git log" optimistically running server-side, I think those sorts of features should definitely be off by default for the reasons noted above.