error: RPC failed; curl transfer closed with outstanding read data remaining

P

27

242

I'm facing this error when I try to clone a repository from GitLab (GitLab 6.6.2 4ef8369):

remote: Counting objects: 66352, done.
remote: Compressing objects: 100% (10417/10417), done.
error: RPC failed; curl 18 transfer closed with outstanding read data remaining
fatal: The remote end hung up unexpectedly
fatal: early EOF
fatal: index-pack failed

The clone is then aborted. How can I avoid this?

Pepsin answered 27/7, 2016 at 16:47 Comment(0)

P

113

After few days, today I just resolved this problem. Generate ssh key, follow this article:

https://help.github.com/articles/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent/

Declare it to

Git provider (GitLab what I am using, GitHub).
Add this to local identity.

Then clone by command:

git clone [email protected]:my_group/my_repository.git

And no error happen.

The above problem

error: RPC failed; curl 18 transfer closed with outstanding read data remaining

because have error when clone by HTTP protocol (curl command).

And, you should increment buffer size:

git config --global http.postBuffer 524288000

Pepsin answered 1/8, 2016 at 15:47 Comment(9)

Change from HTTP to SSH work for me. Config http.postBuffer didn't work. – Schizopod 31/10, 2017 at 9:3

if error is still there , you should edit your ssh config file vi /users/username/.ssh/config and add serverAliveInterval 120 and exit the vi using wq (to save and exit). This will actually prevent the server from timeout and connection break errors. – Larner 5/12, 2017 at 12:56

that's nice, but anyone knows why that happens for 100% cloned? – Bracci 23/10, 2019 at 14:58

Changing http.postBuffer worked for me - thanks! – Oblast 25/3, 2020 at 21:25

after all great steps listed here, git clone ssh://[email protected]/<repository base>/<repository name>.git is the only clone command that worked with me. and there's no need to reference the ssh is in the command at all (in case you're also wondering like i was). – Heap 18/6, 2020 at 20:57

worked for me too for pulling a large solution via a slow vpn connection – Marko 20/7, 2020 at 11:2

Beware: I experienced several issues with npm publish when raising the postBuffer. When I set it down to 50000000, issues were gone. The default value is 1000000, by the way. – Preset 9/10, 2020 at 23:2

changing http.postBuffer 524288000 worked for me.Thank you – Ammadis 30/12, 2022 at 8:29

This works for me: stackoverflow.com/questions/78267333/… – Roubaix 3/4 at 11:47

C

367

It happens more often than not, I am on a slow internet connection and I have to clone a decently huge git repository. The most common issue is that the connection closes and the whole clone is cancelled.

Cloning into 'large-repository'...
remote: Counting objects: 20248, done.
remote: Compressing objects: 100% (10204/10204), done.
error: RPC failed; curl 18 transfer closed with outstanding read data remaining 
fatal: The remote end hung up unexpectedly
fatal: early EOF
fatal: index-pack failed

After a lot of trial and errors and a lot of “remote end hung up unexpectedly” I have a way that works for me. The idea is to do a shallow clone first and then update the repository with its history.

$ git clone http://github.com/large-repository --depth 1
$ cd large-repository
$ git fetch --unshallow

Choking answered 24/5, 2017 at 7:29 Comment(14)

This is the only answer that describes a workaround for the problem without switching to SSH. This worked for me, thanks! – Attainder 10/7, 2017 at 14:36

thx dude, this answer worked for me too. Just change my network with fast internet connection – Crumb 12/7, 2017 at 5:15

The key here is --depth 1 and --unshallow. This also works for fetching an existing repo on slow connection: git fetch --depth 1 then git fetch --unshallow. – Acetum 13/2, 2018 at 9:10

For clarity @AndrewT., the git fetch --unshallow command deals with loss of connection in a more forgiving way than the git clone? And that's what makes the difference here? – Insolvent 9/2, 2019 at 22:6

Now, the git fetch --unshallow command give RPC failed; error – Concealment 5/7, 2019 at 12:25

why turns out failure since 100% cloned, anyone knows the reason? thanks – Bracci 23/10, 2019 at 15:41

Didn't work for me. Failed on the git fetch --unshallow. Guess my repo is too big even for this approach. Only SSH worked. – Carnal 14/2, 2020 at 22:48

If git fetch --unshallow still reports errors, you can use git fetch --depth=100 and then git fetch --depth=200 and then git fetch --depth=300 and so on to fetch repo incrementally. This way works for Linux kernel repo, which is extremely large. – Kronfeld 2/6, 2020 at 5:19

does git fetch --unshallow fetches all branches [as part of history info] ? I am still not seeing few branches. Am I missing something ? – Aeniah 15/6, 2020 at 16:19

as others mentioned, still can't get past git clone and my repo is just a jekyll site with some images. this answer is outdated, going with ssh and secure connections is the only real solution today. – Heap 18/6, 2020 at 15:39

Form me just using git config --global http.postBuffer 524288000 as described at https://mcmap.net/q/12281/-error-rpc-failed-curl-transfer-closed-with-outstanding-read-data-remaining did the trick – Calculating 3/3, 2022 at 23:6

I tried this, but then all the files from the repo (in my case, SolidWorks files) are only 1KB large and cannot be opened. Git still says that they are up-to-date. Anyone else have this issue? – Apprehensive 2/5, 2023 at 11:9

@Kronfeld 's solution git fetch --depth=100 and git fetch --depth=200 worked for me. Below are the comments I ran. git clone http://github.com/large-repository --depth 1 and cd large-repository and git fetch --depth=100 – Nanceenancey 5/3 at 6:6

@ManikandanS this works for me: stackoverflow.com/questions/78267333/… – Roubaix 3/4 at 11:45

P

113