git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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
Previous: Junio C HamanoNext: Jeff King
Message 21 of 43 in “With big repos and slower connections, git clone can be hard to work with”
  1. ellieJun 7, 2024
  2. rsbecker@nexbridge.comJun 7, 2024
  3. ellieJun 8, 2024
  4. rsbecker@nexbridge.comJun 8, 2024
  5. ellieJun 8, 2024
  6. Jeff KingJun 8, 2024
  7. ellieJun 8, 2024
  8. ellieJun 8, 2024
  9. Jeff KingJun 8, 2024
  10. Jeff KingJun 8, 2024
  11. ellieJun 8, 2024
  12. Junio C HamanoJun 8, 2024
  13. ellieJun 8, 2024
  14. Patrick SteinhardtJun 10, 2024
  15. Emily ShafferJun 10, 2024
  16. Junio C HamanoJun 10, 2024
  17. ellieJun 10, 2024
  18. Toon claesJun 13, 2024
  19. Jeff KingJun 11, 2024
  20. Junio C HamanoJun 11, 2024
  21. Sitaram ChamartyJun 29, 2024
  22. Jeff KingJun 11, 2024
  23. Ivan FradeJun 11, 2024
  24. ellieJul 7, 2024
  25. rsbecker@nexbridge.comJul 8, 2024
  26. ellieJul 8, 2024
  27. rsbecker@nexbridge.comJul 8, 2024
  28. ellieJul 8, 2024
  29. Konstantin KhomoutovJul 8, 2024
  30. rsbecker@nexbridge.comJul 8, 2024
  31. ellieJul 8, 2024
  32. rsbecker@nexbridge.comJul 8, 2024
  33. ellieJul 8, 2024
  34. rsbecker@nexbridge.comJul 8, 2024
  35. ellieJul 8, 2024
  36. rsbecker@nexbridge.comJul 8, 2024
  37. Emanuel CziraiJul 8, 2024
  38. Konstantin KhomoutovJul 8, 2024
  39. rsbecker@nexbridge.comJul 8, 2024
  40. ellieJul 14, 2024
  41. ellieJul 24, 2024
  42. EllieSep 8, 2025
  43. EllieSep 30, 2024

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.