8

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)?

learningSteepYep
  • 107
  • 1
  • 1
  • 5

3 Answers3

9

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
bk2204
  • 64,793
  • 6
  • 84
  • 100
  • 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? – learningSteepYep Feb 15 '21 at 13:35
  • Probably because you have a limited refspec set? You could adjust `remote.origin.fetch` or just do the `git remote set-branches`. – bk2204 Feb 15 '21 at 13:39
  • 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. – Michael Mar 25 '22 at 11:21
  • 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 ' – Jason Goemaat May 02 '22 at 20:33
  • 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. – bk2204 May 03 '22 at 00:58
  • 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 . https://stackoverflow.com/questions/34354086/can-i-connect-git-if-i-downloaded-the-code-as-zip – Chris Ruskai Oct 19 '22 at 21:16
6

Update the http post buffer value

git config --global http.postBuffer 1048576000
Raveendra
  • 141
  • 2
  • 6
  • 1
    This setting has a 2Gb limit (32bit) and even maxing it did not resolve the problem for me :( – iCollect.it Ltd Aug 03 '21 at 16:12
  • This didn't solve the problem for me either. – Scott Cowan Jul 12 '22 at 17:42
  • The [Git FAQ](https://git-scm.com/docs/gitfaq#http-postbuffer) 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. – bk2204 Aug 01 '23 at 21:06
1

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 git@ssh.dev.azure.com: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

You could then change the remote repo from Https to SSH via:

git remote set-url origin git@dev.azure.com/my-account/git
orochi
  • 33
  • 6
Barbs
  • 11
  • 1
  • 3