From: Tian Yuchen <a3205153416@gmail.com>
To: phillip.wood@dunelm.org.uk, git@vger.kernel.org
Cc: 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>
Subject: Re: [GSoC][Draft Proposal v4] Refactoring in order to reduce Git's global state
Date: Fri, 27 Feb 2026 23:07:54 +0800 [thread overview]
Message-ID: <86cf5f3f-1459-4281-ae97-24f2d834e099@gmail.com> (raw)
In-Reply-To: <1d43d1d0-bf6b-4806-834e-89f545fab766@gmail.com>
Hi Phillip,
Wow, your reply is very detailed. Appreciate.
> There are four steps below...
Yup, a typo.
> Note that as settings in struct repo_settings are lazily parsed, it is
> only suitable for settings that are already lazily parsed. That means it
> is not a suitable home for any settings that are parsed at startup by
> git_default_config().
This makes sense to me. So for variables in like 'git_default_config()',
their startup parsing nature must be preserved. Will update the proposal
to explicitly distinguish between these different lifecycles.
> Where a function only needs one piece of information from struct
> repository that sounds like a good strategy.
It's much better to pass just that value down rather than passing the
entire 'struct repository', right?
> Although `editor_program` is parsed once, that happens in
> git_default_config() so it is not lazily loaded and making it lazily
> loaded would be a regression as if the config value is invalid we want
> to exit with an error early in the process, not just before we prompt
> the user to edit a file.
Oh, I thought it was lazy-loaded. I completely overlooked the user
experience in terms of a delayed fatal config error also. Will double
check the source code and rewrite this part.
I'm delighted to see more people reviewing my proposal. I've truly
gained valuable insights into Git's design philosophy. My sincere
gratitude to you.
Regards,
Yuchen
next prev parent reply other threads:[~2026-02-27 15:07 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-22 17:59 [GSoC][Draft Proposal] Refactoring in order to reduce Git's global state Tian Yuchen
2026-02-22 18:34 ` Usman Akinyemi
2026-02-23 0:57 ` Tian Yuchen
2026-02-23 1:07 ` [GSoC][Draft Proposal V2] " Tian Yuchen
2026-02-25 17:11 ` [GSoC][Draft Proposal v3] " Tian Yuchen
2026-02-26 9:27 ` Karthik Nayak
2026-02-26 14:03 ` Tian Yuchen
2026-02-26 14:16 ` Tian Yuchen
2026-02-26 17:02 ` [GSoC][Draft Proposal v4] " Tian Yuchen
2026-02-27 9:03 ` Phillip Wood
2026-02-27 15:07 ` Tian Yuchen [this message]
2026-02-27 16:58 ` Tian Yuchen
2026-03-01 16:43 ` Phillip Wood
2026-03-01 16:58 ` Tian Yuchen
2026-03-02 19:06 ` Junio C Hamano
2026-03-03 12:11 ` [GSoC][Draft Proposal v6] " Tian Yuchen
2026-03-08 17:38 ` [GSoC][Draft Proposal v7] " Tian Yuchen
2026-03-14 17:57 ` Tian Yuchen
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=86cf5f3f-1459-4281-ae97-24f2d834e099@gmail.com \
--to=a3205153416@gmail.com \
--cc=ayu.chandekar@gmail.com \
--cc=christian.couder@gmail.com \
--cc=git@vger.kernel.org \
--cc=jltobler@gmail.com \
--cc=karthik.188@gmail.com \
--cc=phillip.wood@dunelm.org.uk \
--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