From: Tian Yuchen <cat@malon.dev>
To: git@vger.kernel.org
Cc: christian@gitlab.com, phillip.wood123@gmail.com,
Tian Yuchen <cat@malon.dev>,
Christian Couder <christian.couder@gmail.com>,
Ayush Chandekar <ayu.chandekar@gmail.com>,
Olamide Caleb Bello <belkid98@gmail.com>
Subject: [PATCH v1 0/1] environment: move protect_hfs and protect_ntfs
Date: Sat, 6 Jun 2026 22:34:12 +0800 [thread overview]
Message-ID: <20260606143412.15443-2-cat@malon.dev> (raw)
In-Reply-To: <20260606143412.15443-1-cat@malon.dev>
Hi everyone,
This series continues the ongoing libification effort by moving the
global **filesystem** variables, protect_hfs and protect_ntfs, into
struct repo_config_values.
Place them within the **per-repository** configuration structure
aligns with our goal of removing global states.
RFC Questions:
1. Should we keep PROTECT_HFS_DEFAULT and PROTECT_NTFS_DEFAULT
in repo_config_values_init()?
void repo_config_values_init(struct repo_config_values *cfg)
{
cfg->attributes_file = NULL;
cfg->apply_sparse_checkout = 0;
cfg->protect_hfs = PROTECT_HFS_DEFAULT;
cfg->protect_ntfs = PROTECT_NTFS_DEFAULT;
cfg->branch_track = BRANCH_TRACK_REMOTE;
}
Or is it better if they are used anywhere other than in environment.c?
If so...
2. Is it worth introducing a Macro or Getter for safe access?
((the_repository->gitdir ? repo_config_values(the_repository)->protect_hfs : 0))
The current approach looks verbose and lacks readability, and
hard-coded 0 and 1 are used as fallback values. I wonder if a macro or a
getter could be introduced, for example...
#define SAFE_PROTECT_HFS(repo) \
(((repo) && (repo)->gitdir && (repo) == the_repository) ? \
repo_config_values(repo)->protect_hfs : PROTECT_HFS_DEFAULT)
...to improve the coding style a bit. Although I am aware that introducing
new macros is generally frowned upon, I would still like to know which
parts this might make difficult to maintain.
3. Note that Derrick attempted to use get_int_config_global to wrap
this kind of Filesystem Level global variables. This approach bypassed
struct repository, did not actually eliminate global state, and the
reviewer politely rejected it. Nevertheless, I am still curious as
to whether this approach might still be inspiring today.
https://lore.kernel.org/git/a42dd9397d07b2dc4a0d7e75bfe1af2e46cad262.1685716420.git.gitgitgadget@gmail.com/
Thanks!
Mentored-by: Christian Couder <christian.couder@gmail.com>
Mentored-by: Ayush Chandekar <ayu.chandekar@gmail.com>
Mentored-by: Olamide Caleb Bello <belkid98@gmail.com>
Signed-off-by: Tian Yuchen <cat@malon.dev>
Tian Yuchen (1):
environment.c: move 'protect_hfs' and 'protect_ntfs' into
'repo_config_values'
compat/mingw.c | 2 +-
environment.c | 8 ++++----
environment.h | 4 ++--
read-cache.c | 7 ++++---
t/helper/test-path-utils.c | 26 ++++++++++++++++----------
5 files changed, 27 insertions(+), 20 deletions(-)
--
2.43.0
prev parent reply other threads:[~2026-06-06 14:35 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-06 14:34 [PATCH v1 1/1] environment.c: move 'protect_hfs' and 'protect_ntfs' into 'repo_config_values' Tian Yuchen
2026-06-06 14:34 ` Tian Yuchen [this message]
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=20260606143412.15443-2-cat@malon.dev \
--to=cat@malon.dev \
--cc=ayu.chandekar@gmail.com \
--cc=belkid98@gmail.com \
--cc=christian.couder@gmail.com \
--cc=christian@gitlab.com \
--cc=git@vger.kernel.org \
--cc=phillip.wood123@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