Subject: Re: [PATCH v3 0/7] builtin/maintenance: implement missing tasks compared to git-gc(1)

From: Junio C Hamano <[email-masked]>
Date: Fri, 02 May 2025 14:07:28 -0700

Derrick Stolee <[email-masked]> writes:

> On 5/2/2025 4:43 AM, Patrick Steinhardt wrote:
>
>> Changes in v3:
>>   - Simplify the heuristic for "rerere-gc" so that we only count the
>>     number of directory entries in ".git/rr-cache", without considering
>>     staleness.
>
> The range-diff was harder to read than just re-reviewing patch 7, but I
> think this v3 is ready to go.

I still do not think "configurable 'rerere gc' basing the decision
on the number of existing rerere entries" adds negative value to the
system.  If there is truly more than N active rerere entries
currently in your repository with your workflow, such a
configuration essentially decides to run 'rerere gc' every time (and
without pruning enough entries to make the next 'rerere gc'
unnecessary), and never otherwise.  It is not like pruning unneeded
loose object files and packing the rest into a packfile, where
running it once (even if it resulted in miniscule packfile due to
misidentification) would remove all the loose object files, which
makes 'repack' unneeded for some time until we accumulate more of
them.  After 'rerere gc', you still will have rerere entries kept.

Until we can implement a meaningful automation (which may require
changing the way rerere entries are stored on disk to help us
cheaply tell if there truly are excessive number of no longer
relevant rerere entries; code that we can readily borrow from
"rerere gc" is enough, as I said), I do not think we should add
extra code to make such a useless decision.  Instead, I would prefer
to see a single "do we or do we not run `rerere gc`?" Boolean, until
that happens.

Other than that, I think the series is a good addition to the
system.  Giving finer grained control is great, and 'git maintenance'
is a much better framework than 'git gc' to do so.

Thanks, all.