From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS53758 23.128.96.0/24 X-Spam-Status: No, score=-3.9 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by dcvr.yhbt.net (Postfix) with ESMTP id 371B11F8C6 for ; Mon, 30 Aug 2021 20:47:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237053AbhH3UrQ (ORCPT ); Mon, 30 Aug 2021 16:47:16 -0400 Received: from cloud.peff.net ([104.130.231.41]:34246 "EHLO cloud.peff.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229708AbhH3UrP (ORCPT ); Mon, 30 Aug 2021 16:47:15 -0400 Received: (qmail 1454 invoked by uid 109); 30 Aug 2021 20:46:21 -0000 Received: from Unknown (HELO peff.net) (10.0.1.2) by cloud.peff.net (qpsmtpd/0.94) with ESMTP; Mon, 30 Aug 2021 20:46:20 +0000 Authentication-Results: cloud.peff.net; auth=none Received: (qmail 10208 invoked by uid 111); 30 Aug 2021 20:46:21 -0000 Received: from coredump.intra.peff.net (HELO sigill.intra.peff.net) (10.0.0.2) by peff.net (qpsmtpd/0.94) with (TLS_AES_256_GCM_SHA384 encrypted) ESMTPS; Mon, 30 Aug 2021 16:46:21 -0400 Authentication-Results: peff.net; auth=none Date: Mon, 30 Aug 2021 16:46:20 -0400 From: Jeff King To: Junio C Hamano Cc: Stef Bon , Git Users Subject: Re: Exec upload-pack on remote with what parameters to get direntries. Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org On Mon, Aug 30, 2021 at 12:43:38PM -0700, Junio C Hamano wrote: > Jeff King 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