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

From: Jeff King <peff@peff.net>
Date: Jan 7, 2011, 05:31 UTC
Message-ID: <20110107053119.GA23177@sigill.intra.peff.net>
In-Reply-To: <20110107052207.GA23128@sigill.intra.peff.net>

On Fri, Jan 07, 2011 at 12:22:07AM -0500, Jeff King wrote:

Show 15 quoted lines

>   refs/mirrors/bundle/torrent
>   refs/mirrors/bundle/http
>   refs/mirrors/fetch/git
>   refs/mirrors/fetch/http
> 
> and the client can decide its preferred way of getting data: a bundle by
> http or by torrent, or connecting directly to some other git repository
> by git protocol or http. It would fetch the appropriate ref, which would
> contain a blob in some method-specific format. For torrent, it would be
> a torrent file. For the others, probably a newline-delimited set of
> URLs. You could also provide a torrent-magnet ref if you didn't even
> want to distribute the torrent file.
> 
> And no matter what the method used, at the end you have some set of refs
> and objects, and you can re-try your (now much smaller fetch).

And I think it is probably obvious to you, Nicolas, since these are problems you have been thinking about for some time, but the reason I am interested in this expanded definition of mirroring is for a few features people have been asking for:

  1. restartable clone; any bundle format is easily restartable using
     standard protocols

  2. avoid too-big clones; I remember the gentoo folks wanting to
     disallow full clones from their actual dev machines and push people
     off to some more static method of pulling. I think not just because
     of restartability, but because of the load on the dev machines

  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

-Peff