Jeff King [off-list ref] writes:
There is no operation to list the tree contents, for example, nor really
even a good way to fetch a single object. The protocol is geared around
efficiently transferring slices of history, so it is looking at sets of
reachable objects (what the client is asking for, and what it claims to
have).
You might be able to cobble something together with shallow and partial
fetches. E.g., something like:
git clone --depth 1 --filter=blob:none --single-branch -b $branch
I was hoping that our support for fetching a single object (not
necessarily a commit) at the protocol level was good enough, so that
Stef's fuse/nfs daemon can fetch the tree object it is interested
in.
There also is an effort, slowly moving to add verbs like object-info
to the protocol to help the vfs usecase, but primitives at too low a
level would be killed by latency, so it is somewhat unknown how
effective it would be.
On Mon, Aug 30, 2021 at 12:43:38PM -0700, Junio C Hamano wrote:
Jeff King [off-list ref] writes:
quoted
There is no operation to list the tree contents, for example, nor really
even a good way to fetch a single object. The protocol is geared around
efficiently transferring slices of history, so it is looking at sets of
reachable objects (what the client is asking for, and what it claims to
have).
You might be able to cobble something together with shallow and partial
fetches. E.g., something like:
git clone --depth 1 --filter=blob:none --single-branch -b $branch
I was hoping that our support for fetching a single object (not
necessarily a commit) at the protocol level was good enough, so that
Stef's fuse/nfs daemon can fetch the tree object it is interested
in.
I don't think there's a clean way to ask for a single object. But
thinking on it more, I suspect you could do something _really_ hacky
using the new object-type filters:
git fetch --filter=object:type=commit --filter=object:type=blob
Because we AND the filters together, no object can satisfy both. But
because we also send any objects which were _explicitly_ requested by
the client, you can now fetch whatever single objects you want.
And as long as you tell the other side you don't have any objects, it
won't send any deltas.
There also is an effort, slowly moving to add verbs like object-info
to the protocol to help the vfs usecase, but primitives at too low a
level would be killed by latency, so it is somewhat unknown how
effective it would be.
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).
-Peff