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

Cloning does not work on available download bandwidth changes

From
PBPaweł Bogusławski <pawel.boguslawski@ib.pl>
Date
May 22, 2024, 15:02 UTC
Message-ID
<ed79092c-c37d-4e4c-aae9-af68cd8c20a0@ib.pl>

Started to clone big git repo on not-too-fast, _stable_ VDSL link (up to 20mbps down)...

     $ git clone https://github.com/googleapis/google-api-go-client
     Cloning into 'google-api-go-client'...
     remote: Enumerating objects: 644446, done.
     remote: Counting objects: 100% (6922/6922), done.
     remote: Compressing objects: 100% (2904/2904), done.
     Receiving objects:   0% (3859/644446), 20.82 MiB | 1.01 MiB/s

...and then started to watch a VOD movie on same link; when VOD buffers data, eats almost all available down bandwidth and leaves only about 100 kB/s for git...

     Receiving objects:   1% (7111/644446), 44.49 MiB | 130.00 KiB/s

...and when VOD stops buffering and whole bandwith is available for git again, git transfer starts to grow...

     Receiving objects:   1% (7660/644446), 50.56 MiB | 575.00 KiB/s
...but finally git throws an error
     error: 181 bytes of body are still expected5 MiB | 1015.00 KiB/s
     fetch-pack: unexpected disconnect while reading sideband packet
     fatal: early EOF
     fatal: index-pack failed
or sometimes:
     error: RPC failed; curl 92 HTTP/2 stream 5 was not closed cleanly: 
CANCEL (err 8)
     error: 6109 bytes of body are still expected
     fetch-pack: unexpected disconnect while reading sideband packet
     fatal: early EOF
     fatal: fetch-pack: invalid index-pack output

No such problems when downloading bigger file (i.e. linux kernel source) with wget or curl instead of git clone (wget/curl transfer drops to about 100 kB/s when VOD buffers and increases to full speed when VOD is not transferring and transfer finishes successfully).

Sounds like a bug in git; should not throw an error on available download bandwidth changes as wget and curl do and should not require any params tuning (to stop users flooding bugtrackers).

git versions tested:
     // Debian 11, amd64
     $ dpkg -s git | grep Version
     Version: 1:2.30.2-1+deb11u2
     // Debian 12, amd64
     $ dpkg -s git | grep Version
     Version: 1:2.39.2-1.1
Similar reports:

https://lore.kernel.org/git/71f2b28b-3e27-4773-8408-2f4c13757b73@gmail.com/ https://lore.kernel.org/git/0d741b90-8307-40cf-b0b3-163203651a57@gmail.com/

Next: brian m. carlson
Message 1 of 6 in “Cloning does not work on available download bandwidth changes”
  1. Paweł BogusławskiMay 22, 2024
  2. brian m. carlsonMay 22, 2024
  3. Paweł BogusławskiMay 22, 2024
  4. Jeff KingMay 23, 2024
  5. Paweł BogusławskiMay 23, 2024
  6. rsbecker@nexbridge.comMay 23, 2024

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.