Re: With big repos and slower connections, git clone can be hard to work with

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 7/8/24 4:32 PM, Konstantin Khomoutov wrote:
On Mon, Jul 08, 2024 at 04:28:25AM +0200, ellie wrote:

[...]
error: RPC failed; curl 92 HTTP/2 stream 5 was not closed cleanly: CANCEL
(err 8)
[...]
It seems extremely unlikely to me to be possibly an ISP issue, for which I
already listed the reasons. An additional one is HTTPS downloads from github
outside of git, e.g. from zip archives, for way larger files work fine as
well.
[...]

What if you explicitly disable HTTP/2 when cloning?

   git -c http.version=HTTP/1.1 clone ...

should probably do this.


Thanks for the idea! I tested it:

$ git -c http.version=HTTP/1.1 clone https://github.com/maliit/keyboard maliit-keyboard
Cloning into 'maliit-keyboard'...
remote: Enumerating objects: 23243, done.
remote: Counting objects: 100% (464/464), done.
remote: Compressing objects: 100% (207/207), done.
error: RPC failed; curl 18 transfer closed with outstanding read data remaining
error: 5361 bytes of body are still expected
fetch-pack: unexpected disconnect while reading sideband packet
fatal: early EOF
fatal: fetch-pack: invalid index-pack output

Sadly, it seems like the error is only slightly different. It was still worth a try. I contacted GitHub support a while ago but it got stuck. If there were resume available such hiccups wouldn't matter, I hope that explains why I suggested that feature.

Regards,

Ellie




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux