RPC failed: curl 56 failure when receiving data from the peer

Question

I have just created a small corporate repository on Azure ( 1 commit per each of 2 branches, totall about 200mb of repo), then I deleted local repository. When I try to clone it to my local machine back( I assume proxy might be an issue here ) I get:

RPC failed: curl 56 failure when receiving data from the peer. 

(However, if that is important, I also see that 100% objects received, 100% deltas resolved.) I am a very distant GIT user, but I have found a way to do the so called shallow clone of repo.

Question is: did I clone the repo with correctly? (it seems yes so far, but do the commands bellow look valid theoretically?):

git clone URL --depth=1 
git remote set-branches origin '*'
git fetch -v --depth=1

Question 2. I still do not understand what was the issue with the error curl56.. Any ideas? P.S. Isn't it possible to download zipped repo from remote to local machine and then somehow link the unzipped directory to the remote(upstream)?

Motherwort

Try cloning your repo in a different computer and connection, then move it to your work computer using a USB, and start working normally on your project. – Gilbertson

Answer 1

This error message means that your machine was unable to receive all of the data from the remote side. It could be that the other side hung up or the connection was interrupted; it's really not possible to say without more information.

If you're using a proxy, then yes, that's likely the problem. Unfortunately, proxies, antivirus programs, non-standard firewalls, and TLS MITM boxes all tend to tamper with connections and they are probably the single biggest cause of this problem with Git. These problems are all due to this software improperly tampering with the connection and can't be fixed by Git. You should report this to your network administrator and ask them to drop or fix the proxy (preferably the former), or you can use a network that doesn't have one.

It is not possible to download a zipped directory and then fill in the Git repository from that. Git stores the entire history of the project and determines what it needs from negotiation which commits are common on both sides. There's no way to get one of those commits from the contents of a zip file, so you'd have no common commits and you'd have to send everything anyway.

The usual way to clone a repository as a shallow one and then unshallow it is this:

$ git clone --depth=1 https://github.com/git/git.git
$ cd git
$ git fetch --unshallow origin

Monjan

I did what you advised before, but without git remote set-branches origin '*' I could not see all branches.. Do you, @bk2204, happen to know why it is like that? – Motherwort

Probably because you have a limited refspec set? You could adjust remote.origin.fetch or just do the git remote set-branches. – Monjan

What is strange to me, is that openssl does work with the same certificates in a pem bundle, but the schannel variant does not work, for bigger(?) repo's. Though I can see some differences with verbose logging on. The schannel complains about authorization issues, but will finish a clone if not too large, or if it is, some multiple fetches on a fresh initiated localgit with the remote git added seem to be a workaround. And the openssl always seem to work. How can that be a proxy issue when the only variable seems to be the sslBackend? I guess I need further investigation in my case. – Quidnunc

What do you mean by 'It is not possible to download a zipped directory and then fill in the Git repository from that.'? All you need is a copy of the .git folder and you have your repository and all the objects/branches/tags that the copy was made from. If you wanted to, you could unzip this to your hard drive and clone from it, then to 'git remote set-url origin <realurl>' – Bidding

Yes, of course, if you zip the .git directory, then you're transferring the repository. However, that's insecure, because it transfers configuration, and it's also not provided by any standard tools. If you have just a zip file of the working tree, which is what the OP was probably asking, then it's not possible to get a repo from that. – Monjan

That's not necessarily all correct. He asked if you could download a zip from the repo and then connect it to the remote. It is possible. Unzip the download and run git init and git remote add <remote_url>. #34354586 – Pilcher

Going back to the OP's original question, is there a git command that can run through your local copy and download any missing files or correct any corrupted files? – Malamut

That's an entirely separate question; please ask it as a new question. There is not sufficient space in the comments to answer a whole new question. – Monjan

Thank you @bk2204, I created a new question: #77586633 – Malamut

Answer 2

Update the http post buffer value

git config --global http.postBuffer 1048576000

Gallion

This setting has a 2Gb limit (32bit) and even maxing it did not resolve the problem for me :( – Wicklund

This didn't solve the problem for me either. – Castra

The Git FAQ mentions specifically that this option should never be needed and will almost always only serve to waste memory. If it works, you have a server or proxy which is seriously broken and shouldn't be on the modern Internet, or you're using an extremely old version of Git with Kerberos. – Monjan

This did resolve the problem for me. After trying to increase the depth one by one this enabled me to do a full --unshallow of the repository. – Fatty

Answer 3

I recently had the same issue while working under a corporate proxy. 'git clone' worked fine for small repos, but not for others that are >100MB. The accepted answer is the best solution. If you are looking for a work-around you could use 'git clone' via SSH.

git clone [email protected]:v3/my-account/git

Check the Microsoft docs to setup your SSH key: https://learn.microsoft.com/en-us/azure/devops/repos/git/use-ssh-keys-to-authenticate?view=azure-devops

If you'd like to change back to HTTPS instead of SSH, you could use:

git remote set-url origin [email protected]/my-account/git

Pronoun