* Parallel pull for ssh-pull
@ 2005-08-02 20:02 barkalow
2005-08-02 20:38 ` Junio C Hamano
0 siblings, 1 reply; 2+ messages in thread
From: barkalow @ 2005-08-02 20:02 UTC (permalink / raw)
To: git
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*
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: Parallel pull for ssh-pull
2005-08-02 20:02 Parallel pull for ssh-pull barkalow
@ 2005-08-02 20:38 ` Junio C Hamano
0 siblings, 0 replies; 2+ messages in thread
From: Junio C Hamano @ 2005-08-02 20:38 UTC (permalink / raw)
To: barkalow; +Cc: git
barkalow@iabervon.org writes:
> 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.
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.
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2005-08-02 20:38 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-08-02 20:02 Parallel pull for ssh-pull barkalow
2005-08-02 20:38 ` Junio C Hamano
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).