On Mon, 4 Feb 2008, Junio C Hamano wrote: > Daniel Barkalow <barkalow@xxxxxxxxxxxx> 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@xxxxxxxxxxxx> > > 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* - 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
