All of lore.kernel.org
 help / color / mirror / Atom feed
From: Patrick Steinhardt <ps@pks.im>
To: Aniket Gupta <aniketgupta3001@gmail.com>
Cc: git@vger.kernel.org, gitster@pobox.com,
	christian.couder@gmail.com, cat@malon.dev, belkid98@gmail.com,
	phillip.wood123@gmail.com
Subject: Re: [PATCH 0/4] environment: move line ending config variables into repo_config_values
Date: Mon, 26 Oct 2026 13:27:37 +0100	[thread overview]
Message-ID: <at9HOXZhVcl53CGX@pks.im> (raw)
In-Reply-To: <20261024220012.486-1-aniketgupta3001@gmail.com>

Hi,

On Sat, Oct 24, 2026 at 10:00:08PM +0000, Aniket Gupta wrote:
> Hi,
> 
> This series moves the global variables behind core.autocrlf, core.eol
> and core.safecrlf into 'struct repo_config_values' to continue the
> libification effort.
> 
> The first patch passes 'repo' to the working tree conversion
> functions which need it to read the values. The other three move one
> variable each just like the earlier conversions.
> 
> An alternative to passing 'repo' would be to store the resolved values
> in 'struct conv_attrs'. I went with passing it since that is what the
> earlier conversions did, but I can change it if you prefer.

This isn't really your fault, but we've had the discussion multiple
times by now that we need to stop moving more config values into
`repo_config_values` until we have a way for how to decouple it from
`the_repository`. The problem here is that the only way to populate
those settings is via `repo_config(git_default_config)`, and that
function will populate the repo config values of `the_repository`.
Consequently, `repo_config_values()` BUGs when called with a different
repostiory.

While these patches _look_ like they libify Git more, they actually do
the exact opposite right now and tie us more and more to
`the_repository`. So I'm inclined to say that we should hold off merging
these patches until we fix that issue, or otherwise we paint ourselves
into a corner.

Patrick

  parent reply	other threads:[~2026-10-26 12:27 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-24 22:00 [PATCH 0/4] environment: move line ending config variables into repo_config_values Aniket Gupta
2026-10-24 22:00 ` [PATCH 1/4] convert: pass 'repo' to the working tree conversion functions Aniket Gupta
2026-10-24 22:00 ` [PATCH 2/4] environment: move auto_crlf into repo_config_values Aniket Gupta
2026-10-24 22:00 ` [PATCH 3/4] environment: move core_eol " Aniket Gupta
2026-10-24 22:00 ` [PATCH 4/4] environment: move global_conv_flags_eol " Aniket Gupta
2026-10-26 12:27 ` Patrick Steinhardt [this message]
2026-10-26 13:10   ` [PATCH 0/4] environment: move line ending config variables " Aniket Gupta
2026-10-26 13:25     ` Patrick Steinhardt
2026-10-26 15:53   ` Junio C Hamano

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=at9HOXZhVcl53CGX@pks.im \
    --to=ps@pks.im \
    --cc=aniketgupta3001@gmail.com \
    --cc=belkid98@gmail.com \
    --cc=cat@malon.dev \
    --cc=christian.couder@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --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 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.