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

From: Ayush Jha <kumarayushjha123@gmail.com>
Date: Feb 18, 2026, 11:04 UTC
Message-ID: <CAFNBzOdqOLKFbDFCp99GvXYWs_Af3PdeXQMjE92y+s92j78GYA@mail.gmail.com>
In-Reply-To: <xmqqpl63b2tm.fsf@gitster.g>

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:

Show 46 quoted lines

>
> 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).
>