Derrick Stolee <stolee@xxxxxxxxx> writes: > On 7/9/2020 10:05 AM, Junio C Hamano wrote: >> For existing callers, "git gc --auto" may want to be left alive, >> merely as a thin wrapper around "git maintenance --auto", and as >> long as the latter is done in the same spirit of the former, i.e. >> perform a lightweight check to see if the repository is so out of >> shape and then do a minimum cleaning, it would be welcomed by users >> if it does a lot more than the current "git gc --auto". > > It's entirely possible that (after the 'maintenance' builtin > stabilizes) that we make 'git gc --auto' become an alias of something > like 'git maintenance run --task=gc --auto' (or itemize all of the > sub-tasks) so that 'git gc --auto' doesn't change behavior. Yes, it is possible, but I doubt it is desirable. The current users of "gc --auto" do not (and should not) care the details of what tasks are performed. We surely have added more stuff that need maintenance since "gc --auto" was originally written, and after people have started using "gc --auto" in their workflows. For example, I think "gc --auto" predates "rerere gc" and those who had "gc --auto" in their script had a moment when suddenly it started to clean stale entries in the rerere database. Were they got upset when it happened? Will they get upset when it starts cleaning up stale commit-graph leftover files? As long as "gc --auto" kept the same spirit of doing a lightweight check to see if the repository is so out of shape to require cleaning and performing a minimum maintenance when it started calling "rerere gc", and as long as "maintenance --auto" does the same, I would think the users would be delighted without complaints. So, I wouldn't worry too much about what exactly happens with the future versions of "gc --auto". The world has changed, and we have more items in the repository that needs maintenance/cruft removal. The command in the new world should deal with these new stuff, too. Thanks.
