Re: [PATCH 1/2] Reduce the number of connects when fetching

From: Daniel Barkalow <barkalow@iabervon.org>
Date: Feb 5, 2008, 19:20 UTC
Message-ID: <alpine.LNX.1.00.0802051417140.13593@iabervon.org>
In-Reply-To: <7v8x20gkue.fsf@gitster.siamese.dyndns.org>

On Mon, 4 Feb 2008, Junio C Hamano wrote:

Show 8 quoted lines

> Daniel Barkalow <barkalow@iabervon.org> writes:
> 
> > This shares the connection between getting the remote ref list and
> > getting objects in the first batch. (A second connection is still used
> > to follow tags)
> > ---
> 
> No signoff.

I think I must have switched from signing off my emails to signing off my commits some time since last october.

Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>

Show 18 quoted lines

> > There's a bug here, fixed in the next patch, but it's just cosmetic (we 
> > hang up on the remote end unexpectedly if we turn out not to need 
> > anything), and I think reorganizing changes to not do that makes the 
> > changes harder to follow.
> 
> > @@ -706,9 +703,34 @@ int cmd_fetch_pack(int argc, const char **argv, const char *prefix)
> >  	if (!dest)
> >  		usage(fetch_pack_usage);
> >  
> > -	ref = fetch_pack(&args, dest, nr_heads, heads, NULL);
> > +	int fd[2];
> > +	struct child_process *conn = git_connect(fd, (char *)dest, args.uploadpack,
> > +                          args.verbose ? CONNECT_VERBOSE : 0);
> 
> Decl after statement.
> 
> But other than that, good job.  I did not realize it would be
> doable this cleanly.

I designed the transport structure to permit it, and the protocol was originally designed to work that way, so it should be easy... the hard part is getting rid of a second connection for fetching new tags, but that's a relatively unusual situation anyway.

> Will squash all three and queue for 'next'.

Great. I assume you'll fix my C99-ism, as well?

	-Daniel
*This .sig left intentionally blank*