Jeff King [off-list ref] 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.
Thanks.
On Mon, Aug 30 2021, Junio C Hamano wrote:
Jeff King [off-list ref] writes:
quoted
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.
On Tue, Aug 31, 2021 at 7:28 AM Ævar Arnfjörð Bjarmason
[off-list ref] wrote:
[Replying again as I used HTML mail by mistake. Sorry.]
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).
Do you mean by someone directly sending object-info requests? I am
working on wiring object-info to some of the existing tools
(cat-file/ls-tree) so this is the general idea about how I see this
being used:
- object-info would be used when it made sense but only if the actual
object being queried is not already fetched locally. If you think of a
virtual filesystem that is backed by, say, partial clones, this mostly
means retrieving metadata information to be displayed to the user.
- Still in the context of a virtual filesystem, metadata is usually
cached locally independently of Git itself, further reducing the need
to call object-info (but, of course, this is a brittle assumption as
it is not controlled by Git).
- git cat-file, for example, would be changed to support real batching
and then send a single request instead of the multiple requests it
does currently.
My point is that I understand where your worry is coming from and as
long as someone can send arbitrary requests then it is possible your
scenario of a heavier server load can potentially happen but as far as
the expected canonical usage, I do not think this would be a problem
and, in fact, under some usage patterns it might make things better
(mostly due to batching support in object-info).
With all that being said, I don' t think making it optional would be
an issue so I have no strong feelings about this. I am fine with
whatever is agreed to be the best approach.
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).
For what it is worth, The same change is now being reviewed in JGit
and there the feature is conditionally enabled. But that was a
side-effect of needing to deploy it to multiple servers before making
the feature available to clients.
--
Bruno Albuquerque | Software Engineer | bga@google.com | +1 650-395-8242