On Fri, Mar 11, 2011 at 07:37, Jeff King <peff@xxxxxxxx> wrote: > On Fri, Mar 11, 2011 at 07:17:31AM -0800, Shawn O. Pearce wrote: > >> >> A simpler way to restartable clone is to facilitate bundles (Nicolas' >> >> idea). Some glue is needed to teach git-fetch/git-daemon to use the >> >> bundles, and git-push to automatically create bundles periodically (or >> >> a new command that can be run from cron). I think this way fit in GSoC >> >> scope better. >> >> I think the cached bundle idea is horrifically stupid in the face of >> the subsequent cached pack idea. JGit already implements cached packs, >> and it works very well. The feature just needs to be back-ported to >> builtin/pack-objects.c, along with some minor edits to my RFC patch to >> git-repack.sh to be able to construct the cached pack. > > I think there is room for both ideas. The cached bundle idea is not just > "here, download this bundle first". It is "here, download this _other > thing_ first, which might be a bundle, another git repo, a torrent, > etc". Fair enough. Though I wouldn't limit this to bundles. Instead I would suggest supporting any valid Git URLs, and then extend our URL syntax to support bundles over http://, rsync://, and torrent. > So yeah, cached packs are a way better solution if you are just going to > have an extra bundle on the same machine. But that's just one use case. > The ability for my server to say "go hit kernel.org first, and then come > back to me to pick up the deltas" is also valuable. Similarly, the > ability to serve an initial bundle off a torrent is useful for extremely > large projects. If we support any URL and don't assume the URL is a bundle, you can point traffic at kernel.org to for example grab Linus' primary repository first, even if he doesn't have a bundle. -- Shawn. -- 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