Parallel pull for ssh-pull

I think I've now got the parallel pull use in ssh-pull to the point where it could be useful to post. Similar stuff should work for http-pull (where it will probably be more interesting), but I have to read more libcurl documentation.

Initial results on ssh-pull are encouraging: on my local ethernet, I moved the current git repository in 16 seconds, unpacked and with the push side acting dumb. I think it was requesting objects about 6 ahead of where it was reading them. I didn't test how much time the pipe spent empty in the final version; when I was printing debugging messages, the pipe was often empty, but it also took 3 times as long, and was therefore probably blocking on debugging output, not the network.

This work is based on some now in -pu; what should I base my patches on? I would ideally like to add a function to one of the patches in -pu and fix a subtle bug in the other, in addition to further patches to actually use the feature in ssh-pull.

	-Daniel
*This .sig left intentionally blank*

barkalow@iabervon.org writes:

The proposed patch queue is just a throw-away branch that I use for the purpose of (1) not to lose patches from people, (2) to ack patches from others, and (3) let people know which ones are under consideration.

Either a patch on top of the pu branch, or a brand new patch on top of the master branch would work fine for me. If you feel some stuff that are in pu need to be fixed or cleaned up, you may want choose the latter --- that way, software archaeologists do not need to know that you made a mess in earlier rounds ;-). If you choose to do so, I would appreciate a warning to tell me which existing patches to drop from pu, although that would probably be pretty clear from the context.

Thanks.