Re: GSoC resumable clone

From: Jeff King <peff@peff.net>
Date: Mar 11, 2011, 15:37 UTC
Message-ID: <20110311153752.GA30329@sigill.intra.peff.net>
In-Reply-To: <AANLkTinrgqLhZK=fQ_+gUanT-zy9Mcbw-y3o7nYV9A-m@mail.gmail.com>

On Fri, Mar 11, 2011 at 07:17:31AM -0800, Shawn O. Pearce wrote:

Show 11 quoted lines

> >> 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".

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.

-Peff