Well, this solution might sound very silly, but can save you in certain conditions.
A friend of mine just ran into accidentally committing very some huge files (four auto-generated files ranging between 3GB to 5GB each) and then made some additional code commits on top of that before realizing the problem that git push
wasn't working any longer!
The files had been listed in .gitignore
but after renaming the container folder, they got exposed and committed! And now there were a few more commits of the code on top of that, but push
was running forever (trying to upload GB of data!) and finally would fail due to Github's file size limits.
The problem with interactive rebase or anything similar was that they would deal with poking around these huge files and would take forever to do anything. Nevertheless, after spending almost an hour in the CLI, we weren't sure if the files (and deltas) are actually removed from the history or simply not included in the current commits. The push wasn't working either and my friend was really stuck.
So, the solution I came up with was:
~/Project-old
.~/Project
). cp -r
the files from ~/Project-old
folder to ~/Project
. mv
ed, and included in .gitignore
properly. .git
folder in the recently-cloned ~/Project
by the old one. That's where the logs of the problematic history lives!push
'ed.The biggest problem with this solution is, it deals with manual copying some files, and also it merges all the recent commits into one (obviously with a new commit-hash.) B
The big benefits are that, it is very clear in every step, it works great for huge files (as well as sensitive ones), and it doesn't leave any trace in history behind!