June 2016 Update: According to this page :
SSH authentication for Team Git repos services is currently in private preview
I recommend that you switch to SSH authentication if possible, because this should completely avoid this problem. (Note that you can use HTTPS and SSH in tandem, even on the same computer .)
If this is not yet included for you, or you otherwise cannot switch to SSH, continue reading.
Original post:
As @Oxymoron mentioned, the problem is that your repository is too large, or more specifically, you are trying to push it too hard.
What? It does not make sense! This is not what HTTP 404 code means!
That doesn't make sense either. * glare in the general direction of Microsoft *
You probably already encountered this and got this error:
Unable to rewind rpc post data - try increasing http.postBuffer
And that most likely led to the fact that you did the git config command that you talked about.
Now, to post a separate answer, I would like to talk about how you can fix this. You will still try to push a smaller set of commits at a time, but it's not always as easy as it sounds. Here is the process:
Determine how many commits are clamped at a time. I usually recommend a binary search to determine how much you can click, but this can be difficult due to the wait time between clicks. In addition, in many repositories, a very large commit occurs, or some commit after that is very large. If you know about such commits, try pushing them yourself. If your repo is small enough, the easiest way is to simply click one commit at a time. Otherwise, try pushing 20-30 commits, decreasing the number if you run into problems.
Assuming you have one branch, master , create a new branch in the same place, for example. master-temp .
Reset master to the last commit in the first group that you want to press. For example. git reset --hard master-temp~100 .
Click this commit ( git push ).
--ff at the last commit of the next group. ( git merge --ff-only master-temp~90 )
Repeat steps 4 and 5 until all commits are pressed.
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 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, this works great and you're done. But what happens if a given commit cannot be pressed, even if this is the only commit you click? First try to press once or twice; there seems to be some inconsistency in how much it takes to fail.
If he still doesn't push, then it's time to rewrite the story.
But I do not want to rewrite my story! My Git journal is nice and clean because I spent a lot of time learning to write large commit messages , and I always keep my commands atomic .
Do not worry, you will still receive your original story when you are done.
Back to the (updated) repo example:
* 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
(Massive commit can be anywhere, or there can be more than one.)
The general idea is that you are doing an interactive redirect ( git rebase -i ) to split the massive commit into several smaller ones.
$ git checkout -b master-temp master $ git rebase -i --root
Note. --root only needed if you need to break the first commit. Otherwise, for example, git rebase -i bbbbbbb .
Change the commit 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 here comes the magic of magit :
$ 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 elements that you have already clicked, even if they are in a different commit. (Note that the Analyzing objects step is the one that takes the longest. This is a Git calculation of how much it can be reused and how much it needs to load.) If you are interested in learning more about how this works, check the Packfiles Git section . Internals docs , possibly after cleaning up on Git Objects .
Did I mention that git is awesome?