Git development
 help / color / mirror / Atom feed
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


      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