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

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

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

> 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.