I was about to commit some media files to a git repository, but then I stopped because I was put off by the huge file size of these files. These files are expected to be obsolete in the future, so I want to avoid polluting the git history with these huge objects. At that point, I don't mind that the history of these media files gets lost.
I've looked around and found many suggestions that use git-filter-branch
. This method requires rewriting the git history, which I want to avoid because it requires attention from other developers on my team.
Now I'm considering to create a submodule within the main repository which contains the media files. Then, whenever the submodule gets too unwieldy, I can either purge the history or use git replace
as described here to reduce the size of a (fresh) checkout.
Is this method sane? If not, what would be the best way to allow for the possibility to remove a git object's data from the history in the future?
What I basically want (which is not possible due to Git's design of commit integrity) is:
AAAA = 1kb AAAA = 1kb
BBBB = 100MB --> (somehow get rid of BBBB's data)
CCCC = 3kb CCCC = 3kb
= 100MB checkout size = 4kb checkout size