git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Kousik Sanagavarapu <five231003@gmail.com>
To: shejialuo <shejialuo@gmail.com>
Cc: git@vger.kernel.org, Patrick Steinhardt <ps@pks.im>
Subject: Re: [PATCH 1/3] repository: move git_*_encoding configs to repo scope
Date: Wed, 16 Oct 2024 22:01:38 +0530	[thread overview]
Message-ID: <Zw/qan9tu/SqKbPf@five231003> (raw)
In-Reply-To: <Zw6SsUyZ0oA0XqMK@ArchLinux>

On Wed, Oct 16, 2024 at 12:05:05AM +0800, shejialuo wrote:
> On Tue, Oct 15, 2024 at 08:01:22PM +0530, Kousik Sanagavarapu wrote:
> > Move "git_commit_encoding" and "git_log_output_encoding" to "struct
> > repository" and amend the functions associated with peeking at these
> > values so that now they take a "struct repository *" argument
> > accordingly.  While at it, rename the functions to repo_*() following
> > our usual convention.
> > 
> > Doing so removes the implicit dependency of these variables on
> > "the_repository", which is better because we now populate these
> > variables per repository.
> > 
> > Signed-off-by: Kousik Sanagavarapu <five231003@gmail.com>
> > 
> > [...]
> > 
> > diff --git a/config.c b/config.c
> > index a11bb85da3..656748692d 100644
> > --- a/config.c
> > +++ b/config.c
> > @@ -1690,13 +1690,15 @@ static int git_default_sparse_config(const char *var, const char *value)
> >  static int git_default_i18n_config(const char *var, const char *value)
> >  {
> >  	if (!strcmp(var, "i18n.commitencoding")) {
> > -		FREE_AND_NULL(git_commit_encoding);
> > -		return git_config_string(&git_commit_encoding, var, value);
> > +		FREE_AND_NULL(the_repository->git_commit_encoding);
> > +		return git_config_string(&the_repository->git_commit_encoding,
> > +					 var, value);
> >  	}
> >  
> >  	if (!strcmp(var, "i18n.logoutputencoding")) {
> > -		FREE_AND_NULL(git_log_output_encoding);
> > -		return git_config_string(&git_log_output_encoding, var, value);
> > +		FREE_AND_NULL(the_repository->git_log_output_encoding);
> > +		return git_config_string(&the_repository->git_log_output_encoding,
> > +					 var, value);
> >  	}
> 
> There are many builtins will execute this config setups by calling
> "config.c::git_default_config" and then "git_default_i18n_config". If we
> need to use "repo" pointer, we may need to wrap this pointer. (This is
> not the problem and it is not hard).
> 
> But what if the "repo" pointer is NULL? We still need to set the value
> of these environment variables. Because when using "git-mailinfo(1)"
> outside of the repo, we still need to set "git_commit_encoding"
> according to the user's config.
> 
> So, from this perspective, I don't think it's a good idea to put these
> two configs into "struct repository". Because we can use these two
> configs outside of the repo, if we put them into "struct repository", it
> is strange.

Makes sense.  Now that I've read this, it does indeed feel strange to
put these configs in "struct repository".

It also raises the question of how correct would it then be that these
configs and the configs similar to this are guarded by
USE_THE_REPOSITORY_VARIABLE macro - since they may not necessarily
depend on "the_repository" too - ie in cases when we are running outside
of any repo.

  parent reply	other threads:[~2024-10-16 16:31 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-15 14:31 [RFC PATCH 0/3] pretty, builtin/mailinfo: don't rely on the_repository Kousik Sanagavarapu
2024-10-15 14:31 ` [PATCH 1/3] repository: move git_*_encoding configs to repo scope Kousik Sanagavarapu
2024-10-15 16:05   ` shejialuo
2024-10-16  6:15     ` Patrick Steinhardt
2024-10-16 17:24       ` Kousik Sanagavarapu
2024-10-17  5:03         ` Patrick Steinhardt
2024-10-17 13:06       ` shejialuo
2024-10-16 16:31     ` Kousik Sanagavarapu [this message]
2024-10-15 14:31 ` [PATCH 2/3] pretty: don't rely on "the_repository" Kousik Sanagavarapu
2024-10-15 14:31 ` [PATCH 3/3] builtin/mailinfo: " Kousik Sanagavarapu
2024-10-15 16:14   ` shejialuo
2024-10-15 19:51 ` [RFC PATCH 0/3] pretty, builtin/mailinfo: don't rely on the_repository Taylor Blau
2024-10-16 17:49   ` Kousik Sanagavarapu

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=Zw/qan9tu/SqKbPf@five231003 \
    --to=five231003@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=ps@pks.im \
    --cc=shejialuo@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;
as well as URLs for NNTP newsgroup(s).