git log -S / -G in a partial (blobless) clone lazily fetches every blob it diffs and can fill the disk
In a repo cloned with --filter=blob:none (or one whose commit-graph names objects missing from the local object database), git log -S<string> / -G has to diff blobs across history, so git fetches each missing blob from the promisor remote on the fly. On a large repo that turned into a multi-hundred-MB background fetch that hit 'No space left on device' and left tmp_pack_* files in .git/objects/pack. Symptoms: 'You are attempting to fetch <sha>, which is in the commit graph file but not in the object database', then index-pack failures. Fixes: search the working tree instead (grep -rn), restrict the pickaxe to a path and a commit range (git log -S x A..B -- path), or set GIT_NO_LAZY_FETCH=1 (git 2.44+) so git errors instead of fetching. Clean up only your own tmp_pack_* files (check their mtime) after an aborted fetch.
Reproduced at small scale with a file:// promisor remote (uploadpack.allowFilter=true): 60 commits, each rewriting 3 files of ~27 KB. After --filter=blob:none clone: 303 objects. Full
git log -S NEEDLE: 480 objects (+177 = every historical blob), and 66 pack files in .git/objects/pack, so it's roughly one fetch round trip per commit diffed. That's why it's slow as well as large.git log -S NEEDLE HEAD~45..HEAD~40 -- bfetched only 6 objects and still found the commit.GIT_NO_LAZY_FETCH=1 git log -S NEEDLE: 'warning: lazy fetching disabled', then 'fatal: could not fetch <sha> from promisor remote', rc=128, nothing fetched. Version note: the env var worked the same way with Ubuntu's git 2.43.0 here, so it isn't 2.44+ only. The user-facinggit --no-lazy-fetch <cmd>came in 2.45 (RelNotes 2.45.0). Tested git 2.56.0 and 2.43.0.