Git error: RPC failed; result=22, HTTP code = 404

I'm using SourceTree on OSX and using Git to push to Visual Studio Online. I get the following error:

>POST git-receive-pack (490857233 bytes)
error: RPC failed; result=22, HTTP code = 404
fatal: The remote end hung up unexpectedly
Everything up-to-date
Completed with errors, see above

I have already tried the following:

git config --global http.postBuffer 524288000

I just ran into a very similar error (for which this answer is the top google result) - the solution was in a comment by @Liviu Chircu

The solution was to put the .git on the end of the url

git clone http://myURL/projectname
Cloning into 'projectname'...
error: RPC failed; result=22, HTTP code = 404
fatal: The remote end hung up unexpectedly

However:

git clone http://myURL/projectname.git

succeeded.

The strange thing is that the original URL without .git succeeded on two linux machines and a windows desktop, but failed on a third linux machine. Including .git makes it work on all machines.

I have just added .git at the end of the git URL while cloning .It's worked

Your repository may be to big, Try to upload in chunks, like using GIT to revert back halfway in the history or so in a new branch, push that, then push the latest commits.

Probably a better workaround, but this is what I was able to do to quickly solve my issue

I was able to push 108.61 MiB, but not 144.64 MiB

Hope this helps.

June 2016 Update: According to this page:

> SSH authentication to Team Services Git repos is currently in private preview

I recommend that you switch to SSH authentication if you are able to, because this should avoid this issue altogether. (Note that you are able to use HTTPS and SSH in tandem, even on the same machine.)

If this hasn't been enabled for you yet, or you are otherwise unable to switch to SSH, keep reading.

---

Original Post:

As @Oxymoron mentioned, the problem is that your repository is too big, or more specifically, you are trying to push too much at once.

> What? That doesn't make sense! That's not what the HTTP 404 code is for!

It doesn't make sense to me either. *glares in Microsoft's general direction*

You probably already ran into this and got an error like this:

Unable to rewind rpc post data - try increasing http.postBuffer

And that is likely what led you to do the git config command that you mentioned.

Now for the purpose of my posting a separate answer: I'd like to expand on how you can fix this. You will still try to push a smaller set of commits at a time, but this is not always as easy as it sounds. Here is the process:

1. Determine how many commits to push at a time. I would normally recommend a binary search to determine how much you can push, but this can be difficult because of the wait time in between pushes. Also, many repos have a very large first commit, or certain commits after that are very large. If you know of such commits, try to push those by themselves. If your repo is small enough, it might be easiest to just push one commit at a time. Otherwise, try to push 20-30 commits, decreasing the number if you run into issues.

2. Assuming you have one branch, master, create a new branch at the same place, e.g. master-temp.

3. Reset master to the last commit in the first group that you want to push. E.g. git reset --hard master-temp~100.

4. Push that commit (git push).

5. Do a --ff merge at the last commit of the next group. (git merge --ff-only master-temp~90)

6. Repeat steps 4 and 5 until all commits are pushed.

As an example, consider this repo:

$ git log --oneline --decorate
* fffffff (HEAD -> master) Commit six
* eeeeeee Commit five
* ddddddd Commit four
* ccccccc Commit three
* bbbbbbb Commit two
* aaaaaaa Commit one

This is what you will do, assuming that you want to push one commit at a time:

$ git checkout -b master-temp master
$ git checkout master
$ git reset --hard aaaaaaa
$ git push origin master
$ git merge --ff-only bbbbbbb
$ git push origin master
$ git merge --ff-only ccccccc
$ git push origin master
$ git merge --ff-only ddddddd
$ git push origin master
$ git merge --ff-only eeeeeee
$ git push origin master
$ git merge --ff-only fffffff
$ git push origin master

Ideally, that works fine, and you're done. But what happens if a given commit can't be pushed, even if that is the only commit you are pushing? First, try pushing once or twice more; there seems to be some inconsistency in how much it takes to fail the push.

If it still won't push, then it's time to rewrite history.

> But I don't want to rewrite my history! My Git log is nice and clean, because I spent lots of time learning how to write great commit messages, and I always keep my commits atomic.

Don't worry, you'll still get your original history when you're done.

Back to the (updated) example repo:

* fffffff (HEAD -> master) Tiny commit five
* eeeeeee Tiny commit four
* ddddddd Tiny commit three
* ccccccc Tiny commit two
* bbbbbbb Tiny commit one
* aaaaaaa This commit is massive

(The massive commit can be anywhere, or there can be more than one.)

The general idea is, you do a interactive rebase (git rebase -i) to split the massive commit into a few smaller ones.

$ git checkout -b master-temp master
$ git rebase -i --root

Note: The --root is only needed if you need to split the very first commit. Otherwise do e.g. git rebase -i bbbbbbb.

Change the commit that you want to split from pick to edit.

$ git reset HEAD^
$ git add somefiles
$ git commit
$ git push origin master-temp
$ git add someotherfiles
$ git commit
$ git push origin master-temp
$ git rebase --continue
$ git push origin master-temp

Now this is where the magit magic happens:

$ git checkout master
switched to branch 'master'
$ git push origin master
POST git-receive-packed (chunked)
remote: Analyzing objects... (1212/1212) (2518523 ms)
remote: Storing packfile... done (48186 ms)
remote: Storing index... done (228 ms)
Pushing to https://example.visualstudio.com/SomeCollection/SomeTeam/_git/MyRepo
To https://example.visualstudio.com/SomeCollection/SomeTeam/_git/MyRepo
 * [new branch]    master -> master
updating local tracking ref 'refs/remotes/origin/master'

The last command will succeed, because Git is smart enough to reuse the items you have already pushed, even if they are in a different commit. (Notice that the Analyzing objects step is the one that takes the longest. This is Git calculating how much it can reuse, and how much it needs to upload.) If you are interested in learning more about how this works, check out the Packfiles section of the Git Internals docs, perhaps after brushing up on Git Objects.

Have I mentioned that Git is awesome?

“The strange thing is that the original URL without .git succeeded on two linux machines and a windows desktop, but failed on a third linux machine. Including .git makes it work on all machines.”

It may be that the git version is too old