All of lore.kernel.org
 help / color / mirror / Atom feed
From: shejialuo <shejialuo@gmail.com>
To: Ayush Chandekar <ayu.chandekar@gmail.com>
Cc: git@vger.kernel.org, ps@pks.im, gitster@pobox.com
Subject: Re: [GSOC PATCH v2 2/2] attr: use `repo_settings_get_attributesfile_path()` and update callers
Date: Tue, 11 Mar 2025 22:39:44 +0800	[thread overview]
Message-ID: <Z9BLMLXJ7Desl-n6@ArchLinux> (raw)
In-Reply-To: <20250310151048.69825-3-ayu.chandekar@gmail.com>

On Mon, Mar 10, 2025 at 08:40:48PM +0530, Ayush Chandekar wrote:
> Update attribute-related functions to retrieve the "core.attributesfile"
> configuration via the new repository-scoped accessor
> `repo_settings_get_attributesfile_path()`. This improves behaviour in
> multi-repository contexts and aligns with the goal of minimizing
> reliance on global state.
> 
> Signed-off-by: Ayush Chandekar <ayu.chandekar@gmail.com>
> ---
>  attr.c               | 28 ++++++++++------------------
>  attr.h               |  7 +++----
>  builtin/check-attr.c |  2 +-
>  builtin/var.c        |  2 +-
>  4 files changed, 15 insertions(+), 24 deletions(-)
> 
> diff --git a/attr.c b/attr.c
> index 0bd2750528..8f28463e8c 100644
> --- a/attr.c
> +++ b/attr.c
> @@ -879,14 +879,6 @@ const char *git_attr_system_file(void)
>  	return system_wide;
>  }
>  
> -const char *git_attr_global_file(void)
> -{
> -	if (!git_attributes_file)
> -		git_attributes_file = xdg_config_home("attributes");
> -
> -	return git_attributes_file;
> -}
> -
>  int git_attr_system_is_enabled(void)
>  {
>  	return !git_env_bool("GIT_ATTR_NOSYSTEM", 0);
> @@ -906,7 +898,7 @@ static void push_stack(struct attr_stack **attr_stack_p,
>  	}
>  }
>  
> -static void bootstrap_attr_stack(struct index_state *istate,
> +static void bootstrap_attr_stack(struct repository *repo, struct index_state *istate,

I have scanned the definition of the "struct index_state", there is a
"struct repository *repo" member in this data structure. This makes me
think why do we need to pass the "struct repository *repo" in the first
place. A design question, should we just use `istate->repo` directly?

>  				 const struct object_id *tree_oid,
>  				 struct attr_stack **stack)
>  {
> @@ -927,8 +919,8 @@ static void bootstrap_attr_stack(struct index_state *istate,
>  	}
>  
>  	/* home directory */
> -	if (git_attr_global_file()) {
> -		e = read_attr_from_file(git_attr_global_file(), flags);
> +	if (repo_settings_get_attributesfile_path(repo)) {
> +		e = read_attr_from_file(repo_settings_get_attributesfile_path(repo), flags);
>  		push_stack(stack, e, NULL, 0);
>  	}
>  
> @@ -946,7 +938,7 @@ static void bootstrap_attr_stack(struct index_state *istate,
>  	push_stack(stack, e, NULL, 0);
>  }
>  
> -static void prepare_attr_stack(struct index_state *istate,
> +static void prepare_attr_stack(struct repository *repo, struct index_state *istate,
>  			       const struct object_id *tree_oid,
>  			       const char *path, int dirlen,
>  			       struct attr_stack **stack)

If we use "istate->repo", we don't even need to change this function.

> @@ -969,7 +961,7 @@ static void prepare_attr_stack(struct index_state *istate,
>  	 * .gitattributes in deeper directories to shallower ones,
>  	 * and finally use the built-in set as the default.
>  	 */
> -	bootstrap_attr_stack(istate, tree_oid, stack);
> +	bootstrap_attr_stack(repo, istate, tree_oid, stack);
>  
>  	/*
>  	 * Pop the "info" one that is always at the top of the stack.

[snip]

Thanks,
Jialuo

  parent reply	other threads:[~2025-03-11 14:39 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-09 15:33 [PATCH] environment: move access to "core.attributesfile" into repo settings Ayush Chandekar
2025-03-10  7:05 ` Patrick Steinhardt
2025-03-10  9:07   ` Ayush Chandekar
2025-03-10 16:16   ` Junio C Hamano
2025-03-10 17:21     ` Ayush Chandekar
2025-03-10 19:25       ` Junio C Hamano
2025-03-10 15:10 ` [GSOC PATCH v2 0/2] Stop depending on `the_repository` for core.attributesfile Ayush Chandekar
2025-03-10 15:10   ` [GSOC PATCH v2 1/2] environment: move access to "core.attributesfile" into repo settings Ayush Chandekar
2025-03-10 21:11     ` Karthik Nayak
2025-03-10 15:10   ` [GSOC PATCH v2 2/2] attr: use `repo_settings_get_attributesfile_path()` and update callers Ayush Chandekar
2025-03-10 21:17     ` Karthik Nayak
2025-03-10 23:08       ` Junio C Hamano
2025-03-11 17:41       ` Ayush Chandekar
2025-03-11 14:39     ` shejialuo [this message]
2025-03-11 17:03       ` Junio C Hamano
2025-03-11 17:20       ` Ayush Chandekar
2025-12-08 20:11         ` Outreachy intern: Request for the completion of this series Olamide Caleb Bello
     [not found]           ` <CAE7as+Zka6J+du+V5zsHzc4eiH+Mzx=dQUnjuJz_Mhnk2RzOPA@mail.gmail.com>
2025-12-09  9:23             ` Bello Olamide

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=Z9BLMLXJ7Desl-n6@ArchLinux \
    --to=shejialuo@gmail.com \
    --cc=ayu.chandekar@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=ps@pks.im \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.