On Fri, Mar 11, 2011 at 7:52 PM, Ilari Liusvaara <ilari.liusvaara@xxxxxxxxxxx> wrote: > On Fri, Mar 11, 2011 at 01:18:45PM +0100, Alexander Miseler wrote: >> On 09.03.2011 22:58, Jeff King wrote: >> >If you have any ideas, please add them to the page! Whether you are >> >available to mentor the project, or simply think it would make a good >> >project and want to inspire others to mentor it, it's appropriate to go >> >there. >> > >> Resumable clone > > This is very very hard. Not so much to implement but to design the way it > can be done without assuming things (like object sort orders) that aren't > stable. Yes it's hard. I have some experimental thing that nearly works [1], although whether it is an acceptable approach is to be seen. If anyone's interested, I'll post it some time 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. [1] The idea of my work above was mentioned elsewhere, history is cut down by path. Each file/dir's history a very long chain of deltas. We can stream deltas (in parallel if needed) over the wire, resuming where the chain stops last time. There are many problems. One is that a deep chain can make git run out of stack, so chains have to be broken down before storing (not done). Another one is that not many deltas can be reused, so it will consume more power than normal clone. But once you clone this way, the cloned repo have lots of delta suitable for another clone (but probably not for anything else). -- Duy -- 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