Re: With big repos and slower connections, git clone can be hard to work with
- From
- ellie <el@horse64.org>
- Date
- Jun 10, 2024, 21:55 UTC
- Message-ID
- <f5c24dfc-8d35-4418-b8f6-0a03d70c0917@horse64.org>
- In-Reply-To
- <xmqq5xug1qrf.fsf@gitster.g>
Sorry for again another total newcomer/outsider question: Is a bundle or pack file something any regular git HTTPS instance would naturally provide when setup the usual ways? Like, if resume relied on that, would this work when following the standard smart HTTP setup procedure https://git-scm.com/book/en/v2/Git-on-the-Server-Smart-HTTP (sorry if I got the wrong link) and then git cloning from that? That would result in the best availability of such a resume feature, if it ever came to be.
Regards,
Ellie
On 6/10/24 10:34 PM, Junio C Hamano wrote:
Show 30 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. > > Perhaps whoever was adding the feature to the public side stopped > after pushing out the absolute minimum and lost interest or > something? We should update the documentation to reflect the > current status (e.g. is it still experimental? what more work do we > need on top of it to make it no longer experimental?), add at least > minimum description for server operators how to configure it on the > server side, etc. (I am assuming that the end-user does not have to > do anything to get the feature, as long as their version of Git is > recent enough). > > Thanks. >