On Fri, Jan 07, 2011 at 12:22:07AM -0500, Jeff King wrote:
> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html