On Thu, Aug 15, 2024 at 04:40:51PM +1000, James Liu wrote: > On Tue Aug 13, 2024 at 5:18 PM AEST, Patrick Steinhardt wrote: > > diff --git a/run-command.c b/run-command.c > > index 45ba544932..94f2f3079f 100644 > > --- a/run-command.c > > +++ b/run-command.c > > @@ -1808,16 +1808,26 @@ void run_processes_parallel(const struct run_process_parallel_opts *opts) > > > > int prepare_auto_maintenance(int quiet, struct child_process *maint) > > { > > - int enabled; > > + int enabled, auto_detach; > > > > if (!git_config_get_bool("maintenance.auto", &enabled) && > > !enabled) > > return 0; > > > > + /* > > + * When `maintenance.autoDetach` isn't set, then we fall back to > > + * honoring `gc.autoDetach`. This is somewhat weird, but required to > > + * retain behaviour from when we used to run git-gc(1) here. > > + */ > > + if (git_config_get_bool("maintenance.autodetach", &auto_detach) && > > + git_config_get_bool("gc.autodetach", &auto_detach)) > > + auto_detach = 1; > > + > > Do the two `*.autodetach` values need to be camel-cased or does it not > matter? I've noticed a mix of both through the codebase so I suppose > it's not case-sensitive. Config keys are case-insensitive in general, and as far as I am aware we typically use the all-lowercase variant when retrieving config keys. On the other hand, in our docs we spell the config keys camel-cased to help the user make sense of it. Patrick