Re: With big repos and slower connections, git clone can be hard to work with

From: Jeff King <peff@peff.net>
Date: Jun 11, 2024, 06:31 UTC
Message-ID: <20240611063123.GB3248245@coredump.intra.peff.net>
In-Reply-To: <xmqq5xug1qrf.fsf@gitster.g>

On Mon, Jun 10, 2024 at 01:34:12PM -0700, Junio C Hamano wrote:

Show 17 quoted lines

> Emily Shaffer <nasamuffin@google.com> writes:
> 
> > It seems to me that packfile URIs and bundle URIs are similar enough
> > that we could work out similar logic for both, no? Or maybe there's
> > something I'm missing about the way bundle offloading differs from
> > packfiles.
> 
> Probably we can deprecate one and let the other one take over?  It
> seems that bundleURI have plenty of documentation, but the only hit
> for packfile URI side I find in the output of
> 
>     $ git grep -i 'pack.*file.*uri' Documentation
> 
> is the description of how the designed protocol extension is
> supposed to work in Documentation/technical/packfile-uri.txt and not
> even the configuration variable uploadpack.blobPackfileURI that
> controls the "experimental" feature is documented.

I think they serve two different purposes. A packfile URI does not have any connectivity guarantees. So it lets a server say "here's all the objects, except for XYZ which you should fetch from this URL". That's good for offloading pieces of a clone, like single large objects.

Whereas bundle URIs require very little cooperation from the server. While a server can advertise bundle URIs, it doesn't need to know about the particular bundle a client grabbed. The client comes back with the usual have/want, just like any other fetching client.

At least that's my understanding. I have to admit I didn't follow the recent bundleURI work all that closely.

-Peff