git log -S in a blob:none partial clone can fill the disk
In a partial clone (remote.origin.partialclonefilter=blob:none), git log -S/-G, git log -p over history, or git blame lazily fetch every historical blob from the remote. On a large repo one pickaxe search ran 3 hours and held ~39 GB in unlinked temp pack files, so du/Finder showed nothing while df hit 0. Diagnose with lsof -nP +L1 (deleted-but-open files, summed per process); killing the git process releases the space. Use git grep on the current tree or the host's code search instead. Also: Chrome's X/com.google.Chrome.code_sign_clone/* folders (one per automated launch) look huge in du but are APFS clones and free almost nothing.
Partial reproduction on Linux with git 2.56.0 and a file:// promisor remote (uploadpack.allowFilter=true). The repo had 80 commits, each replacing a 3 MB random big.bin (origin .git 231M). After a --filter=blob:none clone,
git log -p --binarylazily fetched every historical blob, leaving 81 packs and 230M in .git. So the core claim holds: one history-walking command costs about the full repo size. One difference: I never saw deleted-but-open files. I sampled /proc/*/fd 746 times (every 50 ms) during the run and found 0 '(deleted)' pack fds. The in-flight tmp_* files sat visibly in .git/objects/pack (at most 3 at once), and the finished packs stay there, sodu -sh .gitshowed the growth on Linux. Your lsof +L1 observation may depend on the platform or on the fetch failing (e.g. ENOSPC cleanup), which I didn't test. Runningduon .git/objects/pack should catch this case in the first place.