From: Ayush Jha Date: Wed, 18 Feb 2026 11:04:34 GMT Subject: Re: [RFC GSoC PATCH] environment: move core.trustctime to repo_settings Message-ID: In-Reply-To: Hi Junio, Thank you for the feedback. You are absolutely right that the lazy-loading approach regresses the user experience by delaying detection of configuration errors. To address this, I propose parsing core.trustctime in prepare_repo_settings() in repo-settings.c. This would ensure the configuration is read eagerly during repository initialization, preserving the historical “fail fast” behavior where invalid boolean values cause an immediate fatal error. The repo_settings_get_trust_ctime() accessor would then simply return the pre-parsed value from r->settings.trust_ctime. Does this approach sound reasonable? Thanks, Ayush On Wed, Feb 18, 2026 at 12:44 AM Junio C Hamano wrote: > > Ayush Jha writes: > > > The core.trustctime configuration variable is currently stored as a global in environment.c. This prevents it from being repository-specific, which is problematic when multiple repository instances are used within the same process. > > > > This change continues the effort to move global configuration into struct repo_settings, as discussed in > > <20260208062949.596-1-kumarayushjha123@gmail.com>. > > > > Move trust_ctime into struct repo_settings so that it is associated with a repository instance. > > > > Add repo_settings_get_trust_ctime() to lazily read the > > core.trustctime configuration value, defaulting to true. > > > > Update statinfo.c to use the new accessor instead of the global variable. > > > > Signed-off-by: Ayush Jha > > --- > > environment.c | 5 ----- > > environment.h | 1 - > > repo-settings.c | 7 +++++++ > > repo-settings.h | 8 ++++++++ > > statinfo.c | 4 ++-- > > 5 files changed, 17 insertions(+), 8 deletions(-) > > Doesn't this regress end-user experience when the configuration > variable is misspelled, e.g. "[core] trustctime = bad"? We used to > run git_config_bool() from git_config(git_default_condfig) fairly > early in the program, and would have died before doing anythihng to > give the user a chance to fix the configuration files before going > forward. > > Now we will run deep into codepath and would not notice the > misconfigured core.trustctime until the code happens to ask to > compare the filesystem stat data and in-core index stat data. > > I think this is a recurring theme, e.g. > > https://lore.kernel.org/git/32fceddc-c867-4a47-bde8-c873279edbc1@gmail.com/ > https://lore.kernel.org/git/a881499d-e236-4f8e-a217-b6bce69e3e3c@gmail.com/ > > That other topic Olamide has been working on seems to have settled > *not* to lazily load into repo_settings to avoid the problem. > Instead it reads and parses at the same places in the code path as > before, but into a repo_config_values structure that is associated > with the repository in question (which typically is the_repository). >