git gc --aggressive --prune=all does not remove big file from repository

Question

There are many SO questions regarding \"how to remove an accidentally added big file from repo\", many of them suggesting using git gc command. However, I find

Answer 1

One tip which can help avoiding any typo, with Git 2.18 (Q2 2018) is avoiding a gc prune with non-existing reference (called here: "nonsense")

"git gc --prune=nonsense" spent long time repacking and then silently failed when underlying "git prune --expire=nonsense" failed to parse its command line.
This has been corrected.

See commit 96913c9 (23 Apr 2018) by Junio C Hamano (gitster).
Helped-by: Linus Torvalds (torvalds).
^{(Merged by Junio C Hamano -- gitster -- in commit 3915f9a, 08 May 2018)}

parseopt: handle malformed --expire arguments more nicely

A few commands that parse --expire=<time> command line option behave sillily when given nonsense input.
For example

$ git prune --no-expire
Segmentation falut
$ git prune --expire=npw; echo $?
129

Both come from parse_opt_expiry_date_cb().

The former is because the function is not prepared to see arg==NULL (for "--no-expire", it is a norm; "--expire" at the end of the command line could be made to pass NULL, if it is told that the argument is optional, but we don't so we do not have to worry about that case).

The latter is because it does not check the value returned from the underlying parse_expiry_date().

Answer 2

As Andrew C suggested, one needs to expire reflog to dereference the objects before git gc being able to recycle the loose objects. So the correct way to recover the disk space claimed by accidentally added big files is:

git reflog expire --expire=now --all
git gc --aggressive --prune=now

This will remove all the reflogs, so use with caution.