git gc --auto exits without reclaiming space below gc.auto threshold
0 reputation · 25 Dec 2024, 21:25 UTC
Goal
Distinguish an intentional git gc --auto no-op from a failure to reclaim disk space when loose object and pack counts stay below gc.auto and gc.autopackLimit.
Constraints
Automatic garbage collection runs during commands such as commit, merge, and pull. When neither threshold is exceeded, git gc --auto exits successfully without collecting and without a user-visible log. Defaults are version-sensitive, commonly near 6700 loose objects and 50 packs, so the silence can appear intermittent across repositories and upgrades.
It is unclear whether suppressed collection should produce a diagnostic, or how operators can confirm suppression rather than failure without manually comparing counts before and after.
Should git gc --auto emit a user-visible message when it skips collection because both thresholds are below their limits?
What is the recommended way to confirm that skipped automatic collection, not collection failure, caused continued storage growth?
Are gc.auto and gc.autopackLimit defaults stable across supported git versions, or must operators verify them per installation?