From mboxrd@z Thu Jan 1 00:00:00 1970 From: Junio C Hamano Subject: Re: [RFC PATCH] Reduce the number of connects when fetching Date: Mon, 05 Nov 2007 17:51:47 -0800 Message-ID: <7v1wb4kuoc.fsf@gitster.siamese.dyndns.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: git@vger.kernel.org To: Daniel Barkalow X-From: git-owner@vger.kernel.org Tue Nov 06 02:52:13 2007 Return-path: Envelope-to: gcvg-git-2@gmane.org Received: from vger.kernel.org ([209.132.176.167]) by lo.gmane.org with esmtp (Exim 4.50) id 1IpDbt-0005e6-7w for gcvg-git-2@gmane.org; Tue, 06 Nov 2007 02:52:09 +0100 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753648AbXKFBvz (ORCPT ); Mon, 5 Nov 2007 20:51:55 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753069AbXKFBvz (ORCPT ); Mon, 5 Nov 2007 20:51:55 -0500 Received: from sceptre.pobox.com ([207.106.133.20]:49449 "EHLO sceptre.pobox.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752045AbXKFBvz (ORCPT ); Mon, 5 Nov 2007 20:51:55 -0500 Received: from sceptre (localhost.localdomain [127.0.0.1]) by sceptre.pobox.com (Postfix) with ESMTP id E39902EF; Mon, 5 Nov 2007 20:52:15 -0500 (EST) Received: from pobox.com (ip68-225-240-77.oc.oc.cox.net [68.225.240.77]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by sceptre.sasl.smtp.pobox.com (Postfix) with ESMTP id 791C792ABA; Mon, 5 Nov 2007 20:52:13 -0500 (EST) In-Reply-To: (Daniel Barkalow's message of "Sun, 4 Nov 2007 16:28:38 -0500 (EST)") User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) Sender: git-owner@vger.kernel.org Precedence: bulk X-Mailing-List: git@vger.kernel.org Archived-At: Daniel Barkalow writes: > The idea is to keep the open connection in the data for the transport in > between getting the list of refs and doing anything further. This > therefore moves the connection-handling aspects outside of fetch-pack() > and handles them primarily in transport.c. The idea is very sound. The scripted version of git-fetch used a separate ls-remote only because peek-remote and fetch-pack were separate programs. > ... In particular, I don't know if there's a way to have the > connection end up in a state where objects for more refs can be requested > after some refs have been requested and the resulting objects read. The upload-pack protocol goes "S: here are what I have, C: I want these, C: I have these, S: ok, continue, C: I have these, S: ok, continue, C: I have these, S: ok, I've heard enough, C: done, S: packfile is here", so after packfile generation starts there is nothing further the downloader can say. Otherwise you would be able to do the tag following using the same connection, but that is unfortunately not a case.