Re: 'git gc auto' didn't trigger on large reflog

From: Patrick Steinhardt <ps@pks.im>
Date: Feb 24, 2025, 10:56 UTC
Message-ID: <Z7xQey4S0ewT5rs7@pks.im>
In-Reply-To: <e650f4e4-e267-4f1f-bb3a-c71b1fe0b276@uxp.de>

On Sat, Feb 22, 2025 at 10:50:25PM +0000, Markus Gerstel wrote:

Show 27 quoted lines

> 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