Re: Features from GitSurvey 2010

From: Nicolas Pitre <nico@fluxnic.net>
Date: Feb 1, 2011, 21:36 UTC
Message-ID: <alpine.LFD.2.00.1102011542190.8580@xanadu.home>
In-Reply-To: <201102011451.17456.jnareb@gmail.com>

On Tue, 1 Feb 2011, Jakub Narebski wrote:

Show 13 quoted lines

> On Sun, 30 Jan 2011, Jonathan Nieder wrote:
> > Dmitry S. Kravtsov wrote:
> > 
> > > resumable clone/fetch (and other remote operations)
> > 
> > Jakub Narebski seems to be interested in this and Nicolas Pitre has
> > given some good advice about it.  You can get something usable today
> > by putting up a git bundle for download over HTTP or rsync, so it is
> > possible that this just involves some UI (porcelain) and documentation
> > work to become standard practice.
> 
> I wouldn't say that: it is Nicolas Pitre (IIRC) who was doing the work;
> I was only interested party posting comments, but no code.

No, I'm not working on that. I provided suggestions on how to go about it in the past:

1) The git-archive based solution:
   http://article.gmane.org/gmane.comp.version-control.git/126431
   Relatively simple to implement, with questionable efficiency if you 
   care about the full history, but perfectly suited for shallow clones 
   which is what people with flaky connections should aim for anyway.

2) The bundle based solution:
   http://article.gmane.org/gmane.comp.version-control.git/164699
   (see towards the end of the message)
   This was about BitTorrent distribution, but any resumable transport 
   can be applied to the bundle.
   Extremely simple to implement, as this all can be scripted on top of 
   existing tools.  Good for the bulk of history, but there is always a 
   risk for problems during the update of the repository from the 
   bundle's state up to the most recent commits which has to fall back 
   to the non resumable smart Git protocol.

There is also some possibility that the cache pack work might be leveraged to provide a resumable clone solution similar to #2 above, but that would of course share the same flaws.

> Again, this feature is not very easy to implement, and would require 
> knowledge of git internals including "smart" git transport ("Pro Git"
> book can help there).

The two proposed solutions above require no prior knowledge of the smart Git protocol, and they should be pretty simple to implement. Certainly in the reach of a GSOC student.

Show 10 quoted lines

> > > GitTorrent Protocol, or git-mirror
> > 
> > Sam Vilain and Jonas Fonseca did some good work on this, but it's
> > stalled.
> 
> There was some recent discussion on this on git mailing llist, but
> without any code.
> 
> One would need to know similar areas as for "resumable clone" feature.
> Plus some knowledge on P2P transport in GitTorrent case.

Again, please see

http://article.gmane.org/gmane.comp.version-control.git/164699

This is simple, and with guaranteed results. Why no one was interested in implementing that yet I don't know.

Nicolas