Daniel Barkalow <barkalow@iabervon.org> writes:

quoted text
> 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.

quoted text
> ... 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.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html