From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeff King Subject: Re: GSoC resumable clone Date: Fri, 11 Mar 2011 10:37:52 -0500 Message-ID: <20110311153752.GA30329@sigill.intra.peff.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Cc: Alexander Miseler , Nguyen Thai Ngoc Duy , Ilari Liusvaara , Ramkumar Ramachandra , Jonathan Nieder , Jens Lehmann , Christian Couder , Thomas Rast , git , Pranav Ravichandran To: Shawn Pearce X-From: git-owner@vger.kernel.org Fri Mar 11 16:38:02 2011 Return-path: Envelope-to: gcvg-git-2@lo.gmane.org Received: from vger.kernel.org ([209.132.180.67]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Py4Pi-0000LI-Ga for gcvg-git-2@lo.gmane.org; Fri, 11 Mar 2011 16:38:02 +0100 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754671Ab1CKPhz (ORCPT ); Fri, 11 Mar 2011 10:37:55 -0500 Received: from 99-108-226-0.lightspeed.iplsin.sbcglobal.net ([99.108.226.0]:47686 "EHLO peff.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752417Ab1CKPhy (ORCPT ); Fri, 11 Mar 2011 10:37:54 -0500 Received: (qmail 8233 invoked by uid 107); 11 Mar 2011 15:38:25 -0000 Received: from sigill.intra.peff.net (HELO sigill.intra.peff.net) (10.0.0.7) (smtp-auth username relayok, mechanism cram-md5) by peff.net (qpsmtpd/0.84) with ESMTPA; Fri, 11 Mar 2011 10:38:25 -0500 Received: by sigill.intra.peff.net (sSMTP sendmail emulation); Fri, 11 Mar 2011 10:37:52 -0500 Content-Disposition: inline In-Reply-To: Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Archived-At: 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". 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