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