git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Junio C Hamano <gitster@pobox.com>
Date
Feb 24, 2025, 16:43 UTC
Message-ID
<xmqqeczn70pg.fsf@gitster.g>
In-Reply-To
<Z7xQey4S0ewT5rs7@pks.im>
Patrick Steinhardt <ps@pks.im> writes:
> It's a bit funny, but whether or not `git gc --auto` does anything
> solely depends on the state of the object database.

I guess after adding "auto", we haven't been careful enough to update the triggering condition as we added new kinds of "garbage" to collect? Should we make an exhausitive and authoritative list of gc tasks, document them, and make sure "--auto" pays attention?

Other than objects (packing loose ones, pruning unreferenced loose ones or packing them into cruft packs), we seem to check reflog, worktree, and rerere database.

I do not think there is a readily usable API to query how much stale data is in reflogs that are more than N seconds old, without which "gc --auto" cannot make decisions. I am reasonably sure rerere API does not give you such data, either. I have no idea about the triggering condition of "worktree prune".

Previous: Patrick SteinhardtNext: Patrick Steinhardt
Message 3 of 5 in “'git gc auto' didn't trigger on large reflog”
  1. Markus GerstelFeb 22, 2025
  2. Patrick SteinhardtFeb 24, 2025
  3. Junio C HamanoFeb 24, 2025
  4. Patrick SteinhardtFeb 26, 2025
  5. Junio C HamanoFeb 26, 2025

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.