Make sure to make backup since this is destructive operation, also keep in mind that cloning nor fetching from shallow repo is not supported! To really remove all the history you also need to remove all references to previous commits before pruning.
This leaves the tags and reflog laying around, each of which reference additional commits that can use up space. Note that I would not erase the reflog unless severely needed: it contains local change history used for recovery from mistakes.
There are commands on how to erase the tags or even the reflog in the comments below, and a link to a similar question with a longer answer.
If you still have a lot of space used you may need to remove the tags, which you should try first before removing the reflog.
Note that the first "address" should be a file://, that's important. Also, git will assume your original local file:// address to be the "remote" ("origin"), so you'll need to update the new repository specifying the correct git remote.
git repack can drop unreachable commits without further warning,
making the corresponding entries in .git/shallow invalid, which causes
serious problems when deepening the branches.
One scenario where unreachable commits are dropped by git repack is
when a git fetch --prune (or even a git fetch when a ref was
force-pushed in the meantime) can make a commit unreachable that was
reachable before.
Therefore it is not safe to assume that a git repack -adlf will keep unreachable commits alone (under the assumption that they had not been packed in the first place, which is an assumption at least some of Git's code seems to make).
This is particularly important to keep in mind when looking at the
.git/shallow file: if any commits listed in that file become
unreachable, it is not a problem, but if they go missing, it is a
problem.
One symptom of this problem is that a deepening fetch may now
fail with:
fatal: error in object: unshallow <commit-hash>
To avoid this problem, let's prune the shallow list in git repack when the -d option is passed, unless -A is passed, too (which would force the now-unreachable objects to be turned into loose objects instead of being deleted).
Additionally, we also need to take --keep-reachable and --unpack-unreachable=<date> into account.
Note: an alternative solution discussed during the review of this patch
was to teach git fetch to simply ignore entries in .git/shallow if the
corresponding commits do not exist locally.
A quick test, however, revealed that the .git/shallow file is written during a shallow clone, in which case the commits do not exist, either, but the "shallow" line
does need to be sent.
Therefore, this approach would be a lot more finicky than the approach presented by the this patch.