git push after removing large file

Question

I accidentally commited log/test.log but have never pushed it. I have since done a git rm to get rid of it. But when I try to push, I'm still getting a huge amount of data attempting to be transferred. Shouldn't the git rm fix that problem. If not, how could I fix it?

Answer 1

If you haven't pushed, you can use git rebase -i to edit your commit history, removing both the add and the rm. The one caveat is that you have to be careful not to edit any commits that have already been pushed.

http://blog.madism.org/index.php/2007/09/09/138-git-awsome-ness-git-rebase-interactive

You asked whether you can still do this if there are other changes in the commit and other commits following this one. It depends. You should be able to edit/remove any unpushed commit, not just the most recent. But the rebase might fail if later changes depended heavily on changes in the deleted commit (e.g., you added a file, then edited it in a later commit). If you delete a commit, you will lose all of the changes in that commit. I don't know of a way to remove a single change from a commit. If you don't want to lose the other changes in the test.rb commit, you could generate a patch (with git show <commitid> > /tmp/patch or with the built-in git patch features) before deleting the commit. Then edit your patch file to remove the large test.rb, but leave your desired changes, and reapply the patch to the head.

If you have the problem I mentioned earlier where rebase fails (or you think it would fail), you could save patches for all of your commits after the problem commit, delete them all, and reapply them in order.

Answer 2

Don't revert the commit and then push because the huge file will still be carried around in the history.

Given that you haven't yet pushed it and that the commit you want to redo is the most recent, remove that commit from your history:

$ git reset HEAD^

This will return your index to the state it was in on the parent commit (HEAD^). Now you have a mulligan: add and commit the way you meant to the first time around.

If you've made other subsequent commits, you'll need to git rebase -i <commit> where <commit> is the SHA-1 of the bad commit's parent.

For example (and note the SHA-1 will be different in your repo)

$ git rebase -i 57d0b28

will drop you in an editor that resembles

pick 366eca1 This has a huge file
pick d975b30 delete foo
pick 121802a delete bar

# Rebase 57d0b28..121802a onto 57d0b28
#
# Commands:
#  p, pick = use commit
#  r, reword = use commit, but edit the commit message
#  e, edit = use commit, but stop for amending
#  s, squash = use commit, but meld into previous commit
#
# If you remove a line here THAT COMMIT WILL BE LOST.
# However, if you remove everything, the rebase will be aborted.
#

Replace pick with edit on the line with the heavy commit

edit 366eca1 This has a huge file
pick d975b30 delete foo
pick 121802a delete bar

Save and quit your editor to return to your shell, where you'll see a message of the form

Stopped at 366eca1... This has a huge file
You can amend the commit now, with

    git commit --amend

Once you are satisfied with your changes, run

    git rebase --continue

From there, delete the offending file (--cached removes the file from the index only)

$ git rm --cached big-nasty-file
rm 'big-nasty-file'

amend the commit

$ git commit --amend

and finish the rebase

$ git rebase --continue