Re: [RFC GSoC PATCH] environment: move core.trustctime to repo_settings

>
> 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 <gitster@pobox.com> wrote:
> >
> > Ayush Jha <kumarayushjha123@gmail.com> 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 <kumarayushjha123@gmail.com>
> > > ---
> > >  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).
> >