Re: With big repos and slower connections, git clone can be hard to work with
- From
- ellie <el@horse64.org>
- Date
- Jul 24, 2024, 06:42 UTC
- Message-ID
- <bd5ebf84-5d47-437c-b773-580188cfb001@horse64.org>
- In-Reply-To
- <001b01dad153$ba880ca0$2f9825e0$@nexbridge.com>
For what it's worth, Github support now confirmed to me that it looks like they might have a timeout problem on their side, but until more people report it they likely won't address it. I appreciate their honesty. But I think it shows the vulnerability of a process without resume well.
(Sorry to harp on, I thought this extra info might be interesting.)
Regards,
Ellie
On 7/8/24 6:27 PM, rsbecker@nexbridge.com wrote:
Show 49 quoted lines
> On Monday, July 8, 2024 11:45 AM, Konstantin Khomoutov wrote: >> On Mon, Jul 08, 2024 at 05:14:33PM +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? >> [...] >>> Thanks for the idea! I tested it: >>> >>> $ git -c http.version=HTTP/1.1 clone >>> https://github.com/maliit/keyboard >> >> Over there at SO people are trying all sorts of black magic to combat a > problem >> which manifests itself in a way very similar to yours [1]. I'm not sure > anything from >> there could be of help but maybe worth trying anyway as you can override > any (or >> almost any) Git's configuration setting using that "-c" >> command-line option, so basically test round-trips should not be > painstakingly >> long. >> >> [...] >>> fetch-pack: unexpected disconnect while reading sideband packet >> [...] >>> Sadly, it seems like the error is only slightly different. >> >> I actually find it interesting that in each case a sideband packet is > mentioned. But >> quite possibly it's a red herring anyway. >> >> 1. https://stackoverflow.com/questions/66366582 > > I have customers who hit this problem frequently setting up git. It is 99% > of the time a firewall or proxy configuration issue, not specific to GitHub, > and changes to those usually resolve the problem. The firewall and proxy can > be implemented in the ISP's modem if coming from a home network. That is why > I really think the OP's issue is the network, not something that can > reasonably fixed in git. I think the network speed is also a potential > red-herring unless the speed issue relates to the ISP's configuration. >