Re: Features from GitSurvey 2010

[Shawn Pearce <spearce@spearce.org>]

On Tue, Feb 1, 2011 at 05:51, Jakub Narebski <jnareb@gmail.com> 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.
>
> 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).

I think Nico and I have mostly solved this with the pack caching idea.
 If we cache the pack file, we can resume anywhere in about 97% of the
transfer.  The first 3% cannot be resumed easily, its back to the old
"git cannot be resumed" issue.  Fixing that last 3% is incredibly
difficult... but resuming within the remaining 97% is a pretty simple
extension of the protocol.  The hard part is the client side
infrastructure to remember where we left off and restart.

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

I think this is very similar to resumable clone.  With the cached
pack, clients could use torrent to find it.  But right now Nico and I
are sort of expecting a cached pack to live for about the release
cycle of a project... e.g. only a couple of months.  I don't know if
that can be seeded fast enough on P2P networks to make it useful to
torrent the ~97% of the project that is the cached pack during an
initial clone request.

>> > subtree clone
>>
>> Nguyễn Thái Ngọc Duy and Elijah Newren have done some design and
>> prototyping work.
>
> Git mailing list archives should contain proof of concept / RFC patches
> for this feature.  Quite interesting.

I think Junio has already started thinking about this one.

-- 
Shawn.