]> git.ipfire.org Git - thirdparty/git.git/commit
run-command: honor "gc.auto" for auto-maintenance
authorPatrick Steinhardt <ps@pks.im>
Wed, 13 May 2026 07:31:14 +0000 (09:31 +0200)
committerJunio C Hamano <gitster@pobox.com>
Wed, 13 May 2026 07:57:54 +0000 (16:57 +0900)
commit29364f16242abd490160f66d2d239ac45e1d45fb
treeee0c2eac54d6340fb54f91e0e2ff72d1a8c0a1d6
parent6e95b07e5fd82d248ed7985cd8d45bb20a12aba9
run-command: honor "gc.auto" for auto-maintenance

The "gc.auto" configuration has traditionally been used to turn off
running git-gc(1) as part of our auto-maintenance. We have eventually
switched over to git-maintenance(1) in a95ce12430 (maintenance: replace
run_auto_gc(), 2020-09-17), and with 1942d48380 (maintenance: optionally
skip --auto process, 2020-08-28) we have introduced "maintenance.auto"
to control whether or not to run auto-maintenance.

At that point though we still shelled out to git-gc(1) internally. So
if "gc.auto=0" was set we would still _execute_ git-maintenance(1), but
the command would have exited fast because git-gc(1) itself knew to
honor the config key.

This has recently changed though, as we have adapted the default
maintenance strategy to not use git-gc(1) anymore. The consequence is
that "gc.auto=0" doesn't have an effect anymore, which is a somewhat
surprising change in behaviour for our users.

Adapt `run_auto_maintenance()` so that it knows to also read "gc.auto",
similar to how it also reads both "maintenance.autoDetach" and
"gc.autoDetach".

Reported-by: Jean-Christophe Manciot <actionmystique@gmail.com>
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
run-command.c
t/t7900-maintenance.sh