On Sat, Feb 22, 2025 at 10:50:25PM +0000, Markus Gerstel wrote: > Hi everyone, > > I was looking on a machine that does not normally get any attention. On this > machine a daily cronjob has been running > > git checkout -q master && git fetch && git reset --hard origin/master && > git gc --auto > > for 6 years. The git directory now contains a .git/logs/HEAD file of 180MB > with 823921 lines. > > The repo config contains > > [core] > repositoryformatversion = 0 > filemode = true > bare = false > logallrefupdates = true > > and the system git version is 2.36.6. > > I can't change the git version -or install my own one- so I can't tell > if this has been fixed since. A manual git gc fixed everything, so I > amended the cronjob to just do that instead. > > I was just slightly surprised (and amused) because I expected 'git gc > --auto' to pick this up, so I thought I'd share this with you. It's a bit funny, but whether or not `git gc --auto` does anything solely depends on the state of the object database. This is figured out in `need_to_gc()`, which returns a truish value if either: - You have too many packfiles in the repository. - You have too many loose objects in the repository. If these prerequisites aren't met, then git-gc(1) will skip any other work unrelated to objects, as well, including pruning reflogs. So given your above sequence of commands: > git checkout -q master && git fetch && git reset --hard origin/master && > git gc --auto You may hit an edge case, depending on whether or not git-fetch(1) ends up fetching changes. While git-checkout(1) won't write any reflogs if nothing changes, git-reset(1) writes a reflog entry regardless of whether it performs an "actual" change. So if git-fetch(1) ends up never fetching anything you don't accumulate new loose objects or packfiles, but do end up writing a new reflog entry every single time. The conditions mentioned above won't trigger, and thus the reflog is never pruned, either. Patrick
