summaryrefslogtreecommitdiff
path: root/t/t4013/diff.diff_initial..side
diff options
context:
space:
mode:
authorPatrick Steinhardt <ps@pks.im>2026-05-13 09:31:14 +0200
committerJunio C Hamano <gitster@pobox.com>2026-05-13 16:57:54 +0900
commit29364f16242abd490160f66d2d239ac45e1d45fb (patch)
treeee0c2eac54d6340fb54f91e0e2ff72d1a8c0a1d6 /t/t4013/diff.diff_initial..side
parent6e95b07e5fd82d248ed7985cd8d45bb20a12aba9 (diff)
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>
Diffstat (limited to 't/t4013/diff.diff_initial..side')
0 files changed, 0 insertions, 0 deletions