git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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*
Previous: Junio C HamanoNext: Junio C Hamano
Message 3 of 6 in “Reduce the number of connects when fetching”
  1. Reduce the number of connects when fetchingDaniel Barkalow, Nov 4, 2007
  2. Junio C HamanoNov 6, 2007
  3. Daniel BarkalowNov 6, 2007
  4. Junio C HamanoNov 6, 2007
  5. Johannes SixtNov 6, 2007
  6. Junio C HamanoNov 6, 2007

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.