3

I have never encountered this problem before and have no idea how this is possible. I had a really large directory that I downloaded by mistake into my git repo. I inadvertently did a git add . so the large directory got added to the working tree and when I tried to commit, it didn't allow me to, as the file was too big. Then I didn't do a git rm and directly removed the file from the filesystem. The next time I tried to commit, it didn't allow me to and is still complaining that the directory (which is now no longer present on the filesystem) is too big.

Doesn't removing a file from the filesystem also remove it from the git working tree?

If there is a way to undo my last 2 commits without losing changes,and then re-push it to remote, that would be great.

anonuser0428
  • 11,789
  • 22
  • 63
  • 86

1 Answers1

3

You need to remove it from the index before the commit:

git rm --cached FOLDER_NAME

Since you have it already removed from the file system, the folder should have disappeared now.

If you have added the folder in the most recent commit then you can simply issue:

git commit --amend
git push -f REMOTE BRANCH_NAME

If you have added the folder in penultimate commit, things get a little bit more difficult. I suggest to create a backup of the local repo first.

Follow these steps:

# Rebase the second most recent commits
# -i will open an editor
git rebase -i HEAD~2

In the editor replace pick by edit in the line with the second last commit and save the file. You can now change that commit. Issue:

git rm FOLDER_NAME

# This will open an editor again. You can leave the
# commit message unchanged. Simply save the file
git commit --amend

# Finish the rebase action
git rebase --continue

Now you should be done and the folder is removed from that commmit. You can push using 

git push REMOTE BRANCH_NAME
hek2mgl
  • 152,036
  • 28
  • 249
  • 266
  • how do I find the list of files cached? I need to know the exact name of the directory. Which I do not right now. – anonuser0428 May 25 '15 at 21:36
  • 1
    You can use `git ls-files --cached` – hek2mgl May 25 '15 at 21:39
  • It is not listed in the cached files. I tried to push my commit again but when I did I got the following error: `remote: error: File Path_to_dir/dir_name/filename is 200.96 MB; this exceeds GitHub's file size limit of 100.00 MB` – anonuser0428 May 25 '15 at 21:42
  • So you have added it in the second last commit? – hek2mgl May 25 '15 at 21:45
  • Yes I have 2 commits and I added it in the penultimate one. – anonuser0428 May 25 '15 at 21:45
  • Second, I add that to my answer.. (Please be careful!) – hek2mgl May 25 '15 at 21:48
  • 1
    Ya I added it in the second last commit. @hek2mgl – anonuser0428 May 25 '15 at 21:54
  • Easier than a backup for smoketest-y things is `git clone -s . ../wip; cd ../wip`. If anything you do is worth keeping, push it back. – jthill May 25 '15 at 21:58
  • @jthill Call me a fool, but I like `cp -a repo repo_backup` ;) Just for the case. – hek2mgl May 25 '15 at 22:01
  • @hek2mgl it worked thanks for your help. That was more complex than I expected the solution to be. I feel something like this should be easier to do from a git perspective. – anonuser0428 May 25 '15 at 22:01
  • @anonuser0428 Try that with `svn`! ;) .. (not possible).. Also I think it is as easy as it can be trough the `-i` (interactive mode).. Further note that you can never do that after others have cloned from that repo already (not the case here since you weren't able to push before). You would wake up in a hell of hashes, merges, commits, rebases. – hek2mgl May 25 '15 at 22:04
  • Hmm interesting maybe this is one of those things which will seem more intuitive after getting more familiar with the underlying workings of git. Thanks @hek2mgl for your help. – anonuser0428 May 25 '15 at 22:06
  • You are welcome. Nice to see that your repo works again. – hek2mgl May 25 '15 at 22:07
  • @anonuser0428 If this answers your question, you should accept the answer – hek2mgl May 25 '15 at 22:20