git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: <rsbecker@nexbridge.com>
To: "'ellie'" <el@horse64.org>, <git@vger.kernel.org>
Subject: RE: With big repos and slower connections, git clone can be hard to work with
Date: Mon, 8 Jul 2024 11:31:53 -0400	[thread overview]
Message-ID: <001301dad14b$f8f0e460$ead2ad20$@nexbridge.com> (raw)
In-Reply-To: <2e10070f-2720-4d70-aa15-d4c008cc57bf@horse64.org>

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.


  reply	other threads:[~2024-07-08 15:32 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-07 23:28 With big repos and slower connections, git clone can be hard to work with ellie
2024-06-07 23:33 ` rsbecker
2024-06-08  0:03   ` ellie
2024-06-08  0:35     ` rsbecker
2024-06-08  0:46       ` ellie
2024-06-08  8:43         ` Jeff King
2024-06-08  9:40           ` ellie
2024-06-08  9:44             ` ellie
2024-06-08 10:38               ` Jeff King
2024-06-08 10:35             ` Jeff King
2024-06-08 11:05               ` ellie
2024-06-08 19:00           ` Junio C Hamano
2024-06-08 20:16             ` ellie
2024-06-10  6:46           ` Patrick Steinhardt
2024-06-10 19:04           ` Emily Shaffer
2024-06-10 20:34             ` Junio C Hamano
2024-06-10 21:55               ` ellie
2024-06-13 10:10                 ` Toon claes
2024-06-11  6:31               ` Jeff King
2024-06-11 15:12                 ` Junio C Hamano
2024-06-29  1:53                   ` Sitaram Chamarty
2024-06-11  6:26             ` Jeff King
2024-06-11 19:40               ` Ivan Frade
2024-07-07 23:42         ` ellie
2024-07-08  1:27           ` rsbecker
2024-07-08  2:28             ` ellie
2024-07-08 12:30               ` rsbecker
2024-07-08 12:41                 ` ellie
2024-07-08 14:32                   ` Konstantin Khomoutov
2024-07-08 15:02                     ` rsbecker
2024-07-08 15:14                     ` ellie
2024-07-08 15:31                       ` rsbecker [this message]
2024-07-08 15:48                         ` ellie
2024-07-08 16:23                           ` rsbecker
2024-07-08 17:06                             ` ellie
2024-07-08 17:38                               ` rsbecker
2024-07-08 16:09                         ` Emanuel Czirai
2024-07-08 15:44                       ` Konstantin Khomoutov
2024-07-08 16:27                         ` rsbecker
2024-07-14 12:00                           ` ellie
2024-07-24  6:42                           ` ellie
2025-09-08  2:34                           ` Ellie
2024-09-30 21:01 ` Ellie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='001301dad14b$f8f0e460$ead2ad20$@nexbridge.com' \
    --to=rsbecker@nexbridge.com \
    --cc=el@horse64.org \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).