Git, fatal: The remote end hung up unexpectedly

Question

When I tried to run

git push origin master --force

I just got

Counting objects: 2649, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (1280/1280), done.
error: RPC failed; result=22, HTTP code = 413 | 116 KiB/s   
fatal: The remote end hung up unexpectedly
Writing objects: 100% (2504/2504), 449.61 MiB | 4.19 MiB/s, done.
Total 2504 (delta 1309), reused 2242 (delta 1216)
fatal: The remote end hung up unexpectedly
Everything up-to-date

Is it something to do with not being secure? I tried creating a public key as in the answer for Fatal: The remote end hung up unexpectedly and running it again, but it still doesn't work. Am I not actually using the key? If so, how do I use it?

Answer 1

This looks similar to How do I get github to default to ssh and not https for new repositories. Probably it's worth trying to switch from http protocol to ssh:

$ git remote add origin [email protected]:username/project.git

Answer 2

The problem is due to git/https buffer settings. In order to solve it (taken from Git fails when pushing commit to github)

git config http.postBuffer 524288000

And run the command again

Answer 3

Cause : The default file post size for Git has been exceeded.

Solution :

Navigate to repo.

Run the following command to increase the buffer to 500MB after navigating to the repository:

git config http.postBuffer 524288000

Answer 4

You might get an error like this

error: could not lock config file .git/config: No such file or directory

that is because you dont have a local .git/config file You can get it working by this command

git config --global http.postBuffer 524288000

Answer 5

Other solutions didn't work in my case, doing a garbage collection fixed it for me:

git gc --aggressive

(You can try with just git gc first)

Answer 6

Culprit (in my case):
A high-latency network.

This is not an answer per se but more of an observation that may help others. I found that this error pops up occasionally on high-latency networks (I have to use a Satellite dish for internet access for example). The speed of the network is fine, but the latency can be high. Note: The problem only exists in certain scenarios, but I have not determined what the pattern is.

Temporary mitigation:
I switched networks—I moved to a slower, but lower latency cell network (my phone used as a hotspot)—and the problem disappeared. Note that I can only do this itermittently because my cell connectivity is also intermittent. Plus the bandwidth usage adds costs. I'm also lucky that I have this option available to me. Not everyone does.

I'm sure there is some configuration setting somewhere that makes git—or ssh or curl or whatever times out first—more tolerant of such networks, but I don't know what it is.

A plea to developers:
These kinds of issues are a constant problem for rural populations. Please think of us when you design your systems, tools, and applications. Thank you.

Answer 7

Contrary to one of the other answers - I had the problem on push using ssh - I switched to https and it was fixed.

git remote remove origin
git remote add origin https://github.com/user/repo
git push --set-upstream origin master

Answer 8

This error can also be thrown through missing write permissions on the repository.

---

My concrete case went like this:

1. I created a repo with the root user of my server (via SSH).
2. I installed a git service and created a git linux user that should manage all git-related action.
3. By that time, I had forgotten that the repo was created with the root user in the first place, and the git user simply didn't have the file permissions to write anything into the repository.

Answer 9

Based on the protocol you are using to push to your repo

HTTP

git config --global http.postBuffer 157286400

References:

• https://git-scm.com/docs/git-config#Documentation/git-config.txt-httppostBuffer

SSH

Add the following in ~/.ssh/config file in your linux machine

Host your-gitlab-server.com
  ServerAliveInterval 60
  ServerAliveCountMax 5
  IPQoS throughput

References:

• https://docs.gitlab.com/ee/topics/git/troubleshooting_git.html#check-your-ssh-configuration
• https://unix.stackexchange.com/questions/3026/what-options-serveraliveinterval-and-clientaliveinterval-in-sshd-config-exac
• https://communities.vmware.com/message/2778248

Answer 10

This article have very good explanation and it solved my problem.

git config --global http.postBuffer 157286400

https://confluence.atlassian.com/stashkb/git-push-fails-fatal-the-remote-end-hung-up-unexpectedly-282988530.html

Answer 11

If using GitHub, in the repo's directory, run this command to set http.postBuffer to what appears to be its maximum allowable value for GitHub:

git config http.postBuffer 2147483648

If cloning a repo instead using git clone, it can be cloned with the same option:

git clone -c http.postBuffer=2147483648 [email protected]:myuser/myrepo.git /path/to/myrepo

In both cases, the number above is equivalent to 2 GiB. It is however possible that you will need up to this amount of free memory to be able to use this value.

Ensure that each push to GitHub has commits that don't add more than this size of changes. In fact I would keep the commit push size under 1.8 GiB to be safe. This can require dividing a large commit into smaller commits and pushes.

Why this value?

This specific value is used because at least as of the year 2018, this value was documented (archive link) as the push size limit of GitHub:

we don’t allow pushes over 2GB

Why not set lower?

Some prior answers say to set it to 524288000 (500 MiB), but this number seems arbitrary and without merit. Any lower value should work as long as your push size is not larger than the set value.

Why not set higher?

If instead you set the value to higher than 2 GiB, and if your attempted push size is also higher, you can expect the documented error with GitHub:

remote: fatal: pack exceeds maximum allowed size

Answer 12

Even after configuring post buffer the issue was not resolved.

My problem was solved when I changed my wifi network from broadband to my mobile hotspot. This might not be the logically correct answer but it solved the issue.

Make sure you have good internet speed.

Answer 13

In our case, the problem was a clone that wrote a .git/config file which contained a url entry that was a read only access method. Changing the url from the :// method to the @ method fixed the problem.

Running git remote -v illuminated the issue some.

Answer 14

If you are using git for windows (and you likely are, if you are doing this on a windows machine), and none of the other fixes here worked for you, try going to https://github.com/git-for-windows/git/releases, and getting a version on or after version 2.4.5. Fixed it right up for me.

Answer 15

You probably did clone the repository within an existing one, to solve the problem can simply clone of the repository in another directory and replicate the changes to this new directory and then run the push.

Answer 16

Another addition, since I encountered this error a different way and Google took me here.

My problem was a mismatch of case; one camelCase and one not. Apparently, GIT stops you doing this without telling you why. So if your branches are different from the remote only in the capitalization, try changing them to be identical.

See: Git: 'Master cannot be resolved to branch' after merge

Answer 17

This may occur after updating your OSX platform.

Open Terminal and navigate to your .ssh-folder, and enter ssh-add -K ~/.ssh/id_rsa

Answer 18

Recently I faced the same problem. When cloning a remote repository I got the error as follows:

fatal: the remote end hung up unexpectedly MiB | 7.00 KiB/s
fatal: early EOF
index-pack failed

When I googled the error I was redirected here. And I followed most of the answers but not solved my problem.

The only solution was to re-install my 'Network adapter (WiFi) driver software'. So, what I want to emphasize is the above error can result from the issues in your PC's WiFi driver software, too. If non of the mentioned answers are not working then you can try reinstalling the WiFi driver. It will solve the issue.

You can easily reinstall the WiFi driver as follows:

1. Open network and internet settings
   

2. Select 'Network reset'
   

3. Then select 'Reset now'
   

After rebooting your pc, try git operations successfully (pushing/pulling/cloning).

Answer 19

PLESK Nginx and GIT I was getting this error on plesk git and while pushing a large repo with (who knows what) it gave me this error with HTTP code 413 and i looked into following Server was Plesk and it had nginx running as well as apache2 so i looked into logs and found the error in nginx logs

Followed this link to allow plesk to rebuild configuration with larger file upload.

I skipped the php part for git

After that git push worked without any errors.

Answer 20

In my case I got this error, when pushing with Intellij Idea.

Here is how I traced down my error and fixed it.

• enable debug logging within the terminal, which is never a bad idea :)

set GIT_CURL_VERBOSE=1 set GIT_TRACE=1 

• push via the terminal, not via intellij

git push 
-> fatal: The current branch feature/my-new-feature has no upstream branch.
To push the current branch and set the remote as upstream

Solution was to set the upstream, which must have been gone wrong before:

git push --set-upstream origin feature/my-new-feature

Answer 21

I solved this issue by repacking:

git repack --max-pack-size=100M -a -d

Go to Repository > Open in command prompt in GitHub Desktop Run the following commands:

set GIT_TRACE=1
set GIT_CURL_VERBOSE=1
git push origin <branch>

Answer 22

I happened to have the same error at pull.
I have done the "http.postBuffer" trick. It solved it, but when I wanted to push, I encountered the error again.

What solved my problem:
1. Cloned it to an other folder with an other virtual machine. (Linux).
2. I've done my changes.
3. Pushed it with the original virtual machine where I initially couldn't push. (Windows)

Answer 23

I have the same problem. I noticed from the git web page that the SSH clone URL have the next structure:

[email protected]:user/project.git

I could resolve my problem just changing the ":" by "/", as follows:

[email protected]/user/project.git

may be this can be helpful.

Answer 24

Seems like it can be one of a thousand things.

For me, I was initially pushing master and develop (master had no changes) via SourceTree. Changing this to develop only worked.

Answer 25

I was facing a similar error uploading a large repo, "fatal: The remote end hung up unexpectedly" without any further details.

After a lot of research, here's what I did:

• Using SSH instead of HTTPS, didn't solve the problem.
• Increasing http.postBuffer incrementally up to a very large value, still no luck.
• I figured out that it might be because of large files in the repo (as this is a newly migrated repo from perforce), so I recreated the repo using LFS, setting largeFileThreshold to 40m, which greatly reduced the repo size (from 3.5G to 500M). I thought this will solve the problem, but to my surprise I still faced the same error.

Finally, it occurred to me that may be I'm using an older git client, as I didn't see additional error messages. I upgraded git client to latest (2.20.1), and voila, the error is gone!

Answer 26

Seems almost pointless to add an answer, but I was fighting this for ages when I finally discovered it was Visual Studio Online that was suffering a sporadic outage. That became apparent when VS kept prompting for creds and the VSO website sometimes gave a 500.

Counting objects: 138816, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (38049/38049), done.
error: unable to rewind rpc post data - try increasing http.postBuffer
error: RPC failed; curl 56 SSL read: error:00000000:lib(0):func(0):reason(0), errno 10054
The remote end hung up unexpectedly/138816), 33.30 MiB | 3.00 KiB/s
Writing objects: 100% (138816/138816), 50.21 MiB | 3.00 KiB/s, done.
Total 138816 (delta 100197), reused 134574 (delta 96515)
fatal: The remote end hung up unexpectedly
Everything up-to-date

I set my HTTP post buffer back to 2 MB afterwards, since I actually think it works better with many smaller posts.

Answer 27

None of the above solutions worked for me, however the commit I was pushing was very large.

Very simply, I split it into two commits and pushed each one separately and it went through instantly.

Answer 28

I got this error when I had incorrect keypair in .ssh. Adding the pubkey to github (in settings) fixed this issue for me.

Answer 29

I got this error when I had misspelt my remote branch name

Answer 30

I was able to get around this issue using Git Shell.

Each repository within github.com gives you HTTPS/SSH/Subversion URL's that you can use to download using Shell, see here: http://prntscr.com/8ydguv.
Based on GitHub's recent changes, SSH seems to be the best method.

Command to use in Shell:

git clone "URL of repo goes here w/ no quotes"