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