git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* 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).