Derrick Stolee <stolee@xxxxxxxxx> writes: >> With this as an entry point we'll entirely do away with the old one >> since we don't use the "gc --auto" entry point. > > Users could still erroneously launch two `git gc` commands concurrently > and that will not use the maintenance.lock file. The GC lock is worth > keeping around until we redirect the `gc` command to be an alias that > runs `git maintenance run --task=gc [options]`. Yes, that is prudent. And as long as the traditional gc lock stops the maintenance command from running the gc task, everthing would work consistently ;-) Thanks.
