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?
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"
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
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)
None of the above answers worked for me, but here's what did.
1) delete .git/ from your project
2) clone the remote repo to some new location like your desktop. git clone https://github.com/foo/bar.git
3) move .git/ from the new location into the old location
4) re-commit and push your changes
This may occur after updating your OSX platform.
Open Terminal and navigate to your .ssh-folder, and enter ssh-add -K ~/.ssh/id_rsa
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.
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
This article have very good explanation and it solved my problem.
git config --global http.postBuffer 157286400
The issue cause for me was network settings : I have a "Killer" wifi card which apparently does muck with network packets in a way that SSH and SSL do not like.
To fix the problem, I had to go into "Killer Control Center", "Parameters", and disable "Advanced Stream Detect" - git commands started working again instantly.
my issue (fatal: The remote end hung up unexpectedly) has been resolved by checking repository permission and owner.
git repository files owner must be that user you want push/pull/clone with it.
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
I got this error when I had incorrect keypair in .ssh. Adding the pubkey to github (in settings) fixed this issue for me.
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.
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.
This error can also be thrown through missing write permissions on the repository.
My concrete case went like this:
root user of my server (via SSH).git linux user that should manage all git-related action.root user in the first place, and the git user simply didn't have the file permissions to write anything into the repository.1) cd to the project dir
2) git status
3) git checkout -f HEAD
4) confirm success by pulling down master again to make sure you're up to date if your repo looked incomplete
This works if you get the error in question from Visual Studio's Git when cloning a repo from Bitbucket
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:
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!
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.
This can also happen if any of the commits you're pushing are malformed.
I (unknowingly) had a commit with a malformed Author Email field, but all I was getting was this vague remote end hung up error message. I was able to push other branches just not this one branch, so I started pushing commits from the "bad" branch one at a time until I finally landed at:
Pushing to [email protected]:directangular/unicorn.git
Counting objects: 100% (9/9), done.
Delta compression using up to 20 threads
Writing objects: 100% (5/5), 549 bytes | 549.00 KiB/s, done.
Total 5 (delta 4), reused 0 (delta 0)
remote: error: object 74c7584ff0b93591c19d3a3c19695889dd2274d2: badEmail: invalid author/committer line - bad email
remote: fatal: fsck error in packed object
error: remote unpack failed: index-pack abnormal exit
To github.com:directangular/unicorn.git
! [remote rejected] pizzafeast -> pizzafeast (failed)
error: failed to push some refs to '[email protected]:directangular/unicorn.git'
So it looks like the remote end hung up unexpectedly error is sort of "swallowing" the actual error message, which is probably some kind of malformed commit as I have here.
After fixing the malformed email I was able to push just fine.
Do this to see the key you're using; ssh -vT [email protected]
Then make sure in your build you have this run at the start. eval "$(ssh-agent -s)" ssh-add ~/.ssh/id_rsa
Based on the protocol you are using to push to your repo
HTTP
git config --global http.postBuffer 157286400
References:
SSH
Add the following in ~/.ssh/config file in your linux machine
Host your-gitlab-server.com
ServerAliveInterval 60
ServerAliveCountMax 5
IPQoS throughput
References:
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.
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.
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.
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)
I got this error when I had misspelt my remote branch name
In my case I got this error, when pushing with Intellij Idea.
Here is how I traced down my error and fixed it.
set GIT_CURL_VERBOSE=1 set GIT_TRACE=1
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
I dont think its a good idea to do that but if you have backup in ur machine.. push one more time and then try cloning repo and then remove .git from old dir and move .git from new cloned folder .. git is resolved but because of the issue some files may not upload at git. Push again all from ur back up and then pull it to ur server or the other machine where it get currupted. Right now i just did thid ... Works for me .. and take a backup of your dir before doing this.
And plz correct me if i am wrong. I also dont know what can go wrong after doing this? But this time it really works.
had same problem and try all answer not work, just try another account and that work for me .
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.
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.
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
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.
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.
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
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.
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
Source: Stackoverflow.com