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

>
> On Wed, 18 Feb 2026 at 12:04, Ayush Jha <kumarayushjha123@gmail.com> 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 <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).
> > >
>
> 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