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

Re: upload-pack is slow with lots of refs

From
Johannes Sixt <j.sixt@viscovery.net>
Date
Oct 5, 2012, 06:24 UTC
Message-ID
<506E7D01.8080509@viscovery.net>
In-Reply-To
<CAJo=hJtZ_8H6+kXPpZcRCbJi3LPuuF7M1U8YsjAp-iWvut9oMw@mail.gmail.com>
Am 10/3/2012 21:41, schrieb Shawn Pearce:
Show 22 quoted lines
> On Wed, Oct 3, 2012 at 11:55 AM, Jeff King <peff@peff.net> wrote:
>> 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.

These connections are bidirectional. Upload-pack can just start advertising refs in the "v1" way and announce a "v2" capability and listen for response in parallel. A v2 capable client can start sending "wants" or some other signal as soon as it sees the "v2" capability. Upload-pack, which was listening for responses in parallel, can interrupt its advertisements and continue with v2 protocol from here.

This sounds so simple (not the implementation, of course) - I must be missing something.

-- Hannes
Previous: Jeff KingNext: Shawn Pearce
Message 10 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.