7

I committed some files that I shouldn't commit. Then I added these files in .gitignore and I did this:

git rm -r --cached somefile

and I committed again.

git status shows:

# On branch experiment
nothing to commit, working directory clean

I do git ls-files and these files are not listed.

But when I do git push origin somebranch, these files are still being pushed (they're too large to push to github so it fails).

why is this? what should I do?

Haiyang
  • 1,489
  • 4
  • 15
  • 19

4 Answers4

11

The files are still in your git history. From what's in the question the git history is for example:

$ git log --oneline
aaaaaaa Update .gitignore and remove big files
bbbbbbb accidentally add big files to repo
ccccccc update foo
ddddddd update bar

And pushing fails because of pushing the contents of commit bbbbbbb, it doesn't matter that the file is not in your currently checked out version it's in the project history.

The above can also be confirmed by checking for the history of a specific file/path:

$ git log --all --format=%H -- big.file
aaaaaaa Update .gitignore and remove big files
bbbbbbb accidentally add big files to repo

If big.file is large enough to prevent pushing to github - you need that list of commits to be empty

Obliterating a file from history

There are a number of ways to prevent attempting to push big.file to the remote, but based on the info in the question the simplest of which is:

$ git reset --hard ccccccc

This will remove commits aaaaaaa and bbbbbbb thus there will be no attempt to push big.file to the remote.

The purpose of .gitignore

.gitignore files affect adding files to the repository, they do not affect files already in the index. This is the reason that adding files to .gitignore has had no effect on 'the problem'.

Community
  • 1
  • 1
AD7six
  • 63,116
  • 12
  • 91
  • 123
  • What if you made some other changes in commits aaaaaa and bbbbbb that you want to keep? Is there a way to surgically remove the offending big.file without obliterating the rest of your commit history? – Ethan Fischer May 18 '17 at 01:08
  • I believe what you wanted was `git rm --cached myUnwantedFile` – medley56 Jul 21 '17 at 16:03
  • @medley56 that would keep the file in history. Ethan git rebase, editing commits aaaaaa and bbbbbb - there are many existing questions (also, many of which I've answered) for that. – AD7six Jul 30 '17 at 17:03
2

If you have commited the file . You can cancel the lastest commit bu using:

git reset --soft HEAD^

And then:

git reset filename

And then add the file to .gitignore:

or:

git update-index --assume-unchanged  filename
atupal
  • 16,404
  • 5
  • 31
  • 42
0

The solutions here will work but you will lose other changes in the same commit. If you don't want to lose the other changes in the same commit, and you didn't push the commit yet, you have to change HEAD back to a previous commit, add the changed file and amend:

First find which commit you would like to return to:

$ git log --oneline

Then, it's needed to checkout another branch because you cannot change the HEAD in the active branch:

$ git checkout master

Then, change the head of the branch to an older commit:

$ git branch -f <branch_name> <commit_id>

Then, add the changed file to current commit:

$ git add <filename>

Then, amend the change into current commit:

$ git commit --amend --no-edit

That multi-step solution worked out for me to not lose changes and add new changes to a previous commit.

matrik
  • 104
  • 3
0

Another option, following @AD7six answer, is to create a new branch with no history, so you can push this branch to the remote server ignoring completely the large file.

You can accomplish this by doing:

git checkout --orphan <name_you_choose_for_orphan_branch>
git commit

And then push your changes with

git push <remote-name> <name_you_choose_for_orphan_branch>

Source: How can I purge all the history and push it

kevininhe
  • 569
  • 5
  • 4
  • 1
    Basically just repeats what it says at https://stackoverflow.com/a/34954852/341994. This should be a comment containing a link, not an answer. – matt Nov 24 '22 at 05:02