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

[<rsbecker@nexbridge.com>]

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.