On Mon, Aug 30 2021, Junio C Hamano wrote: > Jeff King <peff@xxxxxxxx> 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.
