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

> Derrick Stolee <stolee@gmail.com> 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.