Dropping a commit in git rebase -i does not reduce the size of .git folder

Question

I have a git repository where the .git folder is 7MB. I have then added and committed an .exe file that is 16MB followed by:

git gc --aggressive && git prune

After the above my .git folder is now 23MB.

Next I have done a git rebase -i and selected drop:

on the commit (c8185ff) that introduced the 16MB file, I completed the rebase and again ran:

git gc --aggressive && git prune

Now when I measure the .git folder its still 23MB.

Should git rebase performed above not remove the commit completely from history - as if the file was never introduced - and hence bring the .git folder back to the 7MB size?

I also tried to do a fresh clone of the repository and the size is still 23MB - I assume the reflog will be cleared when doing a fresh clone.

Answer 1

By default, git gc only prune loose objects older than 2 weeks.

To force a prune on all objects, use --prune=all:

git -c gc.reflogExpire=now gc --prune=all

But, if the object is still reachable through any reference (remote one like origin/master for example, or the reflog), it won't be pruned.

That's why we have to also set the gc.reflogExpire configuration to now.

(For git prune [not necessary after a gc], it's --expire)