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

Re: upload-pack is slow with lots of refs

From
Shawn Pearce <spearce@spearce.org>
Date
Oct 3, 2012, 19:41 UTC
Message-ID
<CAJo=hJtZ_8H6+kXPpZcRCbJi3LPuuF7M1U8YsjAp-iWvut9oMw@mail.gmail.com>
In-Reply-To
<20121003185542.GA3635@sigill.intra.peff.net>
On Wed, Oct 3, 2012 at 11:55 AM, Jeff King <peff@peff.net> wrote:
Show 15 quoted lines
> On Wed, Oct 03, 2012 at 11:53:35AM -0700, Junio C Hamano wrote:
>> Jeff King <peff@peff.net> writes:
>>
>> >> Has there been any work on extending the protocol so that the client
>> >> tells the server what refs it's interested in?
>> >
>> > I don't think so. It would be hard to do in a backwards-compatible way,
>> > because the advertisement is the first thing the server says, before it
>> > has negotiated any capabilities with the client at all.
>>
>> That is being discussed but hasn't surfaced on the list.
>
> Out of curiosity, how are you thinking about triggering such a new
> behavior in a backwards-compatible way? Invoke git-upload-pack2, and
> fall back to reconnecting to start git-upload-pack if it fails?

Basically, yes. New clients connect for git-upload-pack2. Over git:// the remote peer will just close the TCP socket with no messages. The client can fallback to git-upload-pack and try again. Over SSH a similar thing will happen in the sense there is no data output from the remote side, so the client can try again. This has the downside of authentication twice over SSH, which may prompt for a password twice. But the user can get out of this by setting remote.NAME.uploadpack = git-upload-pack and thus force the Git client to use the current protocol if they have a new client and must continue to work over SSH with an old server, and don't use an ssh-agent.

Over HTTP we can request ?service=git-upload-pack2 and retry just like git:// would, or be a bit smarter and say ?service=git-upload-pack&v=2, and determine the protocol support of the remote peer based on the response we get. If we see an immediate advertisement its still the "v1" protocol, if we get back the "yes I speak v2" response like git:// would see, we can continue the conversation from there.

Previous: Jeff KingNext: Jeff King
Message 6 of 24 in “upload-pack is slow with lots of refs”
  1. Ævar Arnfjörð BjarmasonOct 3, 2012
  2. Nguyen Thai Ngoc DuyOct 3, 2012
  3. Jeff KingOct 3, 2012
  4. Junio C HamanoOct 3, 2012
  5. Jeff KingOct 3, 2012
  6. Shawn PearceOct 3, 2012
  7. Jeff KingOct 3, 2012
  8. Sascha CunzOct 4, 2012
  9. Jeff KingOct 5, 2012
  10. Johannes SixtOct 5, 2012
  11. Shawn PearceOct 5, 2012
  12. Johannes SixtOct 8, 2012
  13. Shawn PearceOct 9, 2012
  14. Johannes SixtOct 9, 2012
  15. Johannes SixtOct 9, 2012
  16. Ævar Arnfjörð BjarmasonOct 3, 2012
  17. Jeff KingOct 3, 2012
  18. Ævar Arnfjörð BjarmasonOct 3, 2012
  19. Jeff KingOct 3, 2012
  20. Ævar Arnfjörð BjarmasonOct 3, 2012
  21. Ævar Arnfjörð BjarmasonOct 3, 2012
  22. Jeff KingOct 3, 2012
  23. Ævar Arnfjörð BjarmasonOct 3, 2012
  24. Junio C HamanoOct 3, 2012

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.