From: "Paweł Bogusławski" <pawel.boguslawski@ib.pl>
To: git@vger.kernel.org
Subject: Cloning does not work on available download bandwidth changes
Date: Wed, 22 May 2024 17:02:51 +0200 [thread overview]
Message-ID: <ed79092c-c37d-4e4c-aae9-af68cd8c20a0@ib.pl> (raw)
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 reply other threads:[~2024-05-22 15:02 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-22 15:02 Paweł Bogusławski [this message]
2024-05-22 21:52 ` Cloning does not work on available download bandwidth changes brian m. carlson
2024-05-22 22:58 ` Paweł Bogusławski
2024-05-23 9:04 ` Jeff King
2024-05-23 11:15 ` Paweł Bogusławski
2024-05-23 12:07 ` rsbecker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ed79092c-c37d-4e4c-aae9-af68cd8c20a0@ib.pl \
--to=pawel.boguslawski@ib.pl \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).