One feature I really hope git to add is an easy way to clean up deleted files in the repository. Some times I accidentally check in some large zip files or built files and that really blows up the repository size. Those files stay in there even if I've deleted them. It's a pain to clean them up.
This was probably complicated by the fact I thought you were saying "the feature is there, go RTFM." This is not a regular feature of Git and I think architecturally it's the wrong idea. You want to delete objects, you better go learn rebase, and be prepared to piss off anyone who already has a clone since you're going to have to break fast-forwarding.
Here are the steps I know of to get rid of big blobs. Long and complicate. Is there a better way?
- Find out size of the big blobs and their HASH.
git verify-pack -v .git\objects\pack\pack-HASH.idx | sort -k3n
- Find out the name of a blob hash to verify the blob is the one to delete.
git ls-tree -r HEAD | grep HASH
git ls-tree -r COMMIT_HASH | grep HASH
git log --all --raw --no-abbrev | grep HASH
- Expire all working reflog now, and then prune deleted blob
git reflog expire --expire=all
git gc --prune=now
- Remove a blob.
git push -force
git filter-branch --index-filter 'git rm --cached *.zip --ignore-unmatch ' HEAD
git filter-branch --index-filter 'git rm --cached *.zip --ignore-unmatch ' --prune-empty -- --all
git filter-branch --index-filter 'git update-index --remove webapp.zip' <introduction-revision-sha1>..HEAD
git filter-branch --index-filter 'git update-index --remove webapp.zip' HASH..HEAD
- Clean up reflogs.
rm -Rf .git/refs/original
git reflog expire --expire=now --all
git gc --aggressive
git prune git filter-branch --tree-filter 'rm -f path/to/bigfile.zip'
It may be obvious that this solution is also going to cause the same issue as with rebasing, but just in case, from the man page for filter-branch:
WARNING! The rewritten history will have different object names for all the objects and will not converge with the original branch. You will not be able to easily push and distribute the rewritten branch on top of the original branch. Please do not use this command if you do not know the full implications, and avoid using it anyway, if a simple single commit would suffice to fix your problem. (See the "RECOVERING FROM UPSTREAM REBASE" section in git-rebase(1) for further information about rewriting published history.)