From: ellie <el@horse64.org>
Date: Mon, 08 Jul 2024 15:14:33 GMT
Subject: Re: With big repos and slower connections, git clone can be hard to work with
Message-ID: <2e10070f-2720-4d70-aa15-d4c008cc57bf@horse64.org>
In-Reply-To: <20240708143239.vq47dg7mgh33hykf@carbon>



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