Derrick Stolee <stolee@xxxxxxxxx> writes: > It is important to recognize that there are already several "tasks" that > run inside 'gc' including: > > 1. Expiring reflogs. > 2. Repacking all reachable objects. > 3. Deleting unreachable objects. > 4. Packing refs. > > Before trying to "remove" the gc builtin, we would want these to be > represented in the 'git maintenance run' as tasks. Yup. I like the overall direction of this approach to (1) have a single subcommand that helps all the housekeeping tasks, and to (2) make sure existing housekeeping tasks are supported by the new one. I can understand why it is tempting to start with a new 'main()' under a new subcommand name because we expect to add a lot more tasks, but the name of that subcommand is much less important. As can be seen in the list you have above, "gc" already does a lot more than garbage collection (just #3 is the "garbage collection" proper), as it has grown by following the same approach. What's more important is (2) above. While the tool has grown under the same "gc" name, it was easier to arrange---it fell out naturally as a consequence of the development being an enhancement on top of the prior work. Now that we are reimplementing, we need to actively care. As long as we recognize that, I am perfectly happy with the current effort. 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". Thanks.
