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

[Jeff King <peff@peff.net>]

On Mon, Aug 30, 2021 at 12:43:38PM -0700, Junio C Hamano wrote:

> Jeff King <peff@peff.net> 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.

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