On Monday, July 8, 2024 11:15 AM, ellie wrote: >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. I don't really understand what "it got stuck" means. Is that a colloquialism? What got stuck? That case at GitHub? Have you tried git config --global http.postBuffer 524288000 It might help. The feature being requesting, even if possible, will probably not happen quickly, unless someone has a solid and simple design for this. That is why we are trying to figure out the root cause of your situation, which is not clear to me as to what exactly is failing (possibly a buffer size issue, if this is consistently failing). My experience, as I said before, on these symptoms, is a proxy (even a local one) that is in the way. If you have your linux instance on a VM, the hypervisor may not be configured correctly. Lack of further evidence (all we really have is the curl RPC failure) makes diagnosing this very difficult.
