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

From: Jeff King <peff@peff.net>
Date: Aug 30, 2021, 20:46 UTC
Message-ID: <YS1DnGTDo5ZG8Iw4@coredump.intra.peff.net>
In-Reply-To: <xmqq35qq4t1x.fsf@gitster.g>

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

Show 17 quoted lines

> 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