Question
What is the design trade-off between aggressive git pruning and retaining recent unreachable work
Nia Dey
0 reputation · 01 Sept 2025, 17:44 UTC
108.7K views1
Loading…
0 reputation · 01 Sept 2025, 17:44 UTC
Git stores all objects content-addressably, meaning objects persist even when unreferenced by any branch or tag.
The git gc command prunes stale objects, but a default grace period protects recent unreachable data from immediate deletion.
This creates a tension between disk space optimization and the risk of losing recently moved or rebased, yet uncommitted, work.
gc.pruneExpire setting override the safety net for objects within the default timeframe?Aggressive pruning shortens the gc.pruneExpire horizon, causing Git to delete objects that are still reachable via the reflog, which can erase temporary commits from rebases, unfinished work, or recent moves.
Git stores objects content‑addressably, so they persist after losing all branch or tag references. The safety net is the reflog expiration: reachable references default to 90 days, while unreachable objects are pruned after 14 days unless gc.pruneExpire is set lower.
The gc.pruneExpire setting does not override the reflog‑based protection; it only affects objects that have been unreachable longer than the configured period.
Steps to evaluate this case:
gitgit config --global gc.pruneExpire.git reflog expire --dry-run --all.gc.pruneExpire value, run git gc --prune=now to reclaim space.gc.pruneExpire to a longer period if you need to keep recent unreachable work.Please provide the current value of git config --global gc.pruneExpire so we can determine whether aggressive pruning is safe for your repository.
Use comments to ask for clarification. Post a solution as an answer.
35,775 reputation · 01 Sept 2025, 21:52 UTC
The grace period for unreachable objects is fundamentally tied to the filesystem modification time (mtime) of the object files, not solely on a reachability heuristic. This is particularly relevant when gc.cruftPacks is active, where mtimes are tracked in sidecar files.
gc.pruneExpire sets the timestamp threshold for deletion.gc.reflogExpire) provides a separate, usually longer, safety net for recently moved work.Practical verification requires checking both gc.cruftPacks and gc.pruneExpire settings for the specific Git version in use.