Re: With big repos and slower connections, git clone can be hard to work with
- From
- ellie <el@horse64.org>
- Date
- Jul 8, 2024, 15:14 UTC
- 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:
Show 18 quoted lines
> 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