Re: [RFC PATCH] Reduce the number of connects when fetching
- From
Daniel Barkalow <barkalow@iabervon.org>
- Date
- Nov 6, 2007, 03:04 UTC
- Message-ID
- <Pine.LNX.4.64.0711052150340.7357@iabervon.org>
- In-Reply-To
- <7v1wb4kuoc.fsf@gitster.siamese.dyndns.org>
On Mon, 5 Nov 2007, Junio C Hamano wrote:
Show 10 quoted lines
> Daniel Barkalow <barkalow@iabervon.org> 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.
I figured that had to be the case, due to the way the protocol acts at the beginning.
Show 12 quoted lines
> > ... 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.
It would be nice if this could continue: "C: I also want these, S: ok, heard enough, C: done, S: another packfile is here"; we should be able to identify the end of the packfile on both ends to resume doing other things.
Or, maybe, "C: I also want these single objects, S: here's a thin pack of them", since it's exclusively tags pointing to objects we have just gotten.
-Daniel *This .sig left intentionally blank*