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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Jun 11, 2024 at 08:12:12AM -0700, Junio C Hamano wrote:
> Jeff King <peff@xxxxxxxx> 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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux