Git error fatal the remote end hung up unexpectedly

When I tried to run

git push origin master --force

I just got

Counting objects: 2649, done.
Delta compression uses 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 the answer for Fatal: The remote end hung up unexpectedly and rerunning it, but it still doesn’t work. Am I not actually using the key? If so, how do I use it?

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 git@github.com: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

answered Oct 28, 2020 at 2:11

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.

answered Jul 20, 2014 at 15:09

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.

answered Jul 30, 2015 at 17:04

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.

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

answered Apr 22, 2020 at 10:39

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>

answered Mar 15, 2021 at 22:48

This may occur after updating your OSX platform.

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

answered Dec 7, 2016 at 10:23

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.

answered Apr 5, 2019 at 12:58

For us the problem was that we had a ton of files that should have instead been managed by git lfs.

We did the following to resolve the problem:

# Soft reset so you can author a new commit
git reset --soft HEAD~1

# Install git lfs
git lfs install

# Track large files of a specified file type YMMV
git lfs track "*.uasset" "*.umap"

# Re-add everything
git add .

# Author a new commit
git commit -m "git lfs ftw"

# Push
git push

answered Dec 16, 2021 at 23:17

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

answered Apr 15, 2021 at 22:13

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

git@github.com:user/project.git

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

git@github.com/user/project.git

may be this can be helpful.

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.

answered Jul 23, 2017 at 0:07

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.