From: Ayush Jha Date: Wed, 18 Feb 2026 11:45:33 GMT Subject: Re: [RFC GSoC PATCH] environment: move core.trustctime to repo_settings Message-ID: In-Reply-To: Hello Olamide, Thank you for the update. Since you are already working on a more robust pattern (repo_config_values) for this, I will drop my patch to avoid conflicts and duplicated effort. Best regards, Ayush On Wed, Feb 18, 2026 at 4:52 PM Bello Olamide wrote: > > On Wed, 18 Feb 2026 at 12:04, Ayush Jha wrote: > > > > 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). > > > > > Hello Ayush > Thank you for your interest in this topic. > > As Junio pointed out in his response to you, I have submitted patches that > settle not to lazily load into repo_settings. but instead to read and parse into > the struct repo_config_values structure associated with the repository. > > I will continue working to move other repo specific configuration variables > in environment.c into this struct once these patches have been accepted. > Thanks > > Olamide