Re: With big repos and slower connections, git clone can be hard to work with
- From
Sitaram Chamarty <sitaramc@gmail.com>
- Date
- Jun 29, 2024, 01:53 UTC
- Message-ID
- <Zn9o_UCjtf9MuwvH@sita-dell>
- In-Reply-To
- <xmqqh6dzy0mr.fsf@gitster.g>
On Tue, Jun 11, 2024 at 08:12:12AM -0700, Junio C Hamano wrote:
Show 14 quoted lines
> Jeff King <peff@peff.net> writes: > > > 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. > > Yes, a bundle being a self-contained "object-store + tips", it is > a much more suitable building block for offloading clone traffic.
[Adding mricon to cc]
Apologies for jumping in so late...
Gitolite supports this out of the box. Just a couple of lines change to the rc file and users can just run `rsync` (still mediated and access controlled by gitolite) to get a bundle. Admittedly the first call by someone may take some time but it *is* resumable.
See [1] for details.
[1]: https://github.com/sitaramc/gitolite/blob/master/src/commands/rsync