5

Somehow I have a really large local repository because I added over 2 GB of files by accident and without thinking tried to push this. I aborted, removed the files and did a recommit, but when I try to git push origin master to Bitbucket, it fails with:

fatal: The remote end hung up unexpectedly

My .git file is still huge, even though I have since long removed the unneeded files. Since the push is over 2 GB, Bitbucket says I need to set the http.postBuffer to a higher number. I've done this many times but after about 15 tries I want to just start over.

git status gives me this:

On branch master
Your branch is ahead of 'origin/master' by 4 commits.
  (use "git push" to publish your local commits)

But since the push never works, how do I fix it? Worst case scenario I could just blast the repo and rebuild it, but I'd like to know if there is a way to reset the push since it keeps failing.

Tensigh
  • 1,030
  • 5
  • 22
  • 44
  • 1
    How did you "remove the unneeded files"? This is a version control system, and it keeps older revisions (including deleted files) as well. You need to rewrite history to completely erase any record (and then probably garbage-collect). – Thilo Nov 30 '16 at 07:40
  • 1
    Possible duplicate of [How to remove/delete a large file from commit history in Git repository?](http://stackoverflow.com/questions/2100907/how-to-remove-delete-a-large-file-from-commit-history-in-git-repository) – Thilo Nov 30 '16 at 07:41
  • This question comes up fairly often here, but you can look into using `git filter-branch` or `git rebase -i` to remove those bad commits. Do so immediately, so they don't get further buried. – Tim Biegeleisen Nov 30 '16 at 07:41

2 Answers2

4

You can do it by git reset

git reset --hard <commit-id>

You can get commit-id by using git log

You will lose all your work between HEAD and the commit you selected

weigreen
  • 1,232
  • 8
  • 13
  • 1
    I think an interactive rebase would make more sense. Using a rebase would allow later work to be retained. Both rebase and your answer would rewrite the history of the branch, so neither method is better from this point of view. – Tim Biegeleisen Nov 30 '16 at 07:51
  • This won't do anything to any other branches or tags that may also contain the huge files. – Thilo Nov 30 '16 at 07:52
4

The weigreen’s answer will help when the problematic commit is the most recent one, in other cases you’ll need to rewrite the history. I would prefer an interactive rebase.

git rebase -i <some-commit-before-the-problematic-one>

It will display the list of commits along with the default action to pick them as they are. If you want to keep a part of the problematic commit, change pick to edit on that line. If you prefer to remove it at all, just delete the line. If you choose to edit that commit, Git will put the working tree into the state like when you’ve just done the problematic commit. Change what you need and amend the commit:

git commit --amend

After that, let Git finish the rebase using

git rebase --continue
Melebius
  • 6,183
  • 4
  • 39
  • 52
  • That would have worked best. I ended up doing a hard reset, then forced the push. Your solution would have worked better had I not already done a hard reset. :( – Tensigh Nov 30 '16 at 08:54
  • @Tensigh Until you run `git gc`, you can still access the removed refs using `git reflog`. – Melebius Nov 30 '16 at 08:56
  • Okay, thanks. Now that I see that, how do I roll back? – Tensigh Nov 30 '16 at 09:00
  • @Tensigh Make a new branch at the desired ref: `git branch ` or move an existing branch there: `git branch -f ` – Melebius Nov 30 '16 at 09:03