git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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/



             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).