On Mon, Jun 10, 2024 at 01:34:12PM -0700, Junio C Hamano wrote: > Emily Shaffer <nasamuffin@xxxxxxxxxx> 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
