On Fri, May 02, 2025 at 02:07:28PM -0700, Junio C Hamano wrote: > 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. Ok, fair enough. I'll stick with the "maintenance.rerere-gc.auto" config as integer, but will adapt it so that any positive value will cause us to invoke `git rerere gc` when the "rr-cache" directory exists and has at least one entry. The reason I want to keep it as an integer is mostly to stay consistent with all the other "maintenance.*.auto" settings, even though it does not add a lot of value right now. Patrick
