From: Patrick Steinhardt <ps@pks.im>
To: Markus Gerstel <2025@uxp.de>
Cc: git@vger.kernel.org
Subject: Re: 'git gc auto' didn't trigger on large reflog
Date: Mon, 24 Feb 2025 11:56:59 +0100 [thread overview]
Message-ID: <Z7xQey4S0ewT5rs7@pks.im> (raw)
In-Reply-To: <e650f4e4-e267-4f1f-bb3a-c71b1fe0b276@uxp.de>
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
next prev parent reply other threads:[~2025-02-24 10:57 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-22 22:50 'git gc auto' didn't trigger on large reflog Markus Gerstel
2025-02-24 10:56 ` Patrick Steinhardt [this message]
2025-02-24 16:43 ` Junio C Hamano
2025-02-26 11:39 ` Patrick Steinhardt
2025-02-26 16:10 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Z7xQey4S0ewT5rs7@pks.im \
--to=ps@pks.im \
--cc=2025@uxp.de \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).