From: Junio C Hamano <gitster@pobox.com>
To: Ayush Jha <kumarayushjha123@gmail.com>
Cc: git@vger.kernel.org, Phillip Wood <phillip.wood123@gmail.com>,
Olamide Caleb Bello <belkid98@gmail.com>,
Christian Couder <christian.couder@gmail.com>,
Karthik Nayak <karthik.188@gmail.com>,
Justin Tobler <jltobler@gmail.com>,
Ayush Chandekar <ayu.chandekar@gmail.com>,
Siddharth Asthana <siddharthasthana31@gmail.com>,
Lucas Seiki Oshiro <lucasseikioshiro@gmail.com>,
Chandra Pratap <chandrapratap3519@gmail.com>
Subject: Re: [RFC GSoC PATCH] environment: move core.trustctime to repo_settings
Date: Tue, 17 Feb 2026 11:13:57 -0800 [thread overview]
Message-ID: <xmqqpl63b2tm.fsf@gitster.g> (raw)
In-Reply-To: <20260215112331.22-1-kumarayushjha123@gmail.com> (Ayush Jha's message of "Sun, 15 Feb 2026 16:53:30 +0530")
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).
next prev parent reply other threads:[~2026-02-17 19:14 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-15 11:23 [RFC GSoC PATCH] environment: move core.trustctime to repo_settings Ayush Jha
2026-02-17 19:13 ` Junio C Hamano [this message]
2026-02-18 11:04 ` Ayush Jha
2026-02-18 11:22 ` Bello Olamide
2026-02-18 11:45 ` Ayush Jha
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqpl63b2tm.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=ayu.chandekar@gmail.com \
--cc=belkid98@gmail.com \
--cc=chandrapratap3519@gmail.com \
--cc=christian.couder@gmail.com \
--cc=git@vger.kernel.org \
--cc=jltobler@gmail.com \
--cc=karthik.188@gmail.com \
--cc=kumarayushjha123@gmail.com \
--cc=lucasseikioshiro@gmail.com \
--cc=phillip.wood123@gmail.com \
--cc=siddharthasthana31@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox