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

Re: Resumable clone/Gittorrent (again) - stable packs?

From
Jeff King <peff@peff.net>
Date
Jan 7, 2011, 19:17 UTC
Message-ID
<20110107191719.GA6175@sigill.intra.peff.net>
In-Reply-To
<20110107185218.GA16645@LK-Perkele-VI.localdomain>
On Fri, Jan 07, 2011 at 08:52:18PM +0200, Ilari Liusvaara wrote:
Show 21 quoted lines
> On Fri, Jan 07, 2011 at 12:31:19AM -0500, Jeff King wrote:
> > 
> >   3. people on low-bandwidth servers who fork major projects; if I write
> >      three kernel patches and host a git server, I would really like
> >      people to only fetch my patches from me and get the rest of it from
> >      kernel.org
> 
> One client-side-only feature that could be useful:
> 
> Ability to contact multiple servers in sequence, each time advertising
> everything obtained so far. Then treat the new repo as clone of the last
> address.
> 
> This would e.g. be very handy if you happen to have local mirror of say, Linux
> kernel and want to fetch some related project without messing with alternates
> or downloading everything again:
> 
> git clone --use-mirror=~/repositories/linux-2.6 git://foo.example/linux-foo
> 
> This would first fetch everything from local source and then update that
> from remote, likely being vastly faster.

I'm not clear in your example what ~/repositories/linux-2.6 is. Is it a repo? In that case, isn't that basically the same as --reference? Or is it a local mirror list?

If the latter, then yeah, I think it is a good idea. Clients should definitely be able to ignore, override, or add to mirror lists provided by servers. The server can provide hints about useful mirrors, but it is up to the client to decide which methods are useful to it and which mirrors are closest.

Of course there are some servers who will want to do more than hint (e.g., the gentoo case where they really don't want people cloning from the main machine). For those cases, though, I think it is best to provide the hint and to reject clients who don't follow it (e.g., by barfing on somebody who tries to do a full clone). You have to implement that rejection layer anyway for older clients.

-Peff
Previous: Ilari LiusvaaraNext: Ilari Liusvaara
Message 15 of 22 in “Re: Resumable clone/Gittorrent (again) - stable packs?”
  1. Zenaan HarknessJan 6, 2011
  2. Shawn PearceJan 6, 2011
  3. John WyzerJan 10, 2011
  4. Sam VilainJan 10, 2011
  5. Nguyen Thai Ngoc DuyJan 11, 2011
  6. J.H.Jan 11, 2011
  7. Nguyen Thai Ngoc DuyJan 11, 2011
  8. Nicolas PitreJan 6, 2011
  9. Zenaan HarknessJan 7, 2011
  10. Nicolas PitreJan 7, 2011
  11. Jeff KingJan 7, 2011
  12. Jeff KingJan 7, 2011
  13. Zenaan HarknessJan 7, 2011
  14. Ilari LiusvaaraJan 7, 2011
  15. Jeff KingJan 7, 2011
  16. Ilari LiusvaaraJan 7, 2011
  17. Jeff KingJan 7, 2011
  18. Ilari LiusvaaraJan 7, 2011
  19. Jeff KingJan 7, 2011
  20. Sam VilainJan 10, 2011
  21. Nguyen Thai Ngoc DuyJan 10, 2011
  22. Nicolas PitreJan 10, 2011

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.