Re: [PATCH v3 0/3] environment: clean up repository config handling

[Junio C Hamano <gitster@pobox.com>]

Patrick Steinhardt <ps@pks.im> writes:

> On Fri, Aug 07, 2026 at 04:59:29PM +0800, Tian Yuchen wrote:
>> Hi all,
>> 
>> This series contains several cleanup patches for repository configuration
>> handling.
>> 
>> No functional changes are intended. The patches make the related code
>> more consistent and easier to maintain by improving documentation,
>> formatting, and the organization of repo_config_values.
>> 
>> RFC:
>> If there are other small cleanups in this area that would be useful to
>> include, suggestions are welcome.
>
> Somewhat unrelated to this patch series, but I was wondering whether you
> plan to drop the limitation in `repo_config_values()` that requires that
> the passed-in repository is `the_repository`. This limitation is
> starting to create problems as more and more of our infrastructure is
> migrating into `struct repo_config_values`, so using a different repo
> than `the_repository` is starting to become harder and harder in our
> codebase.
>
> Thanks!
>
> Patrick

Hmph, that is an interesting point.  What is our plan to really
enable the use of repository instances other than 'the_repository'
here?  They of course need to be initialized with repo_init(),
but is that enough to sensibly use the embedded 'repo_settings'
and 'repo_config_values' structures?  (By the way, it is not
entirely clear to me why we need both and how we sift variables
between them.)  Some code paths need to work outside a repository
and still need to know about per-user or per-system settings.
We were perfectly happy reading from global variables when we had
the majority of them there.  It is my understanding that they are
now found in 'repo_config_values' or 'repo_settings' associated
with 'the_repository', which I think is something we cannot
really avoid doing.  Unless we try to get rid of 'the_repository'
and instead have free-standing 'repo_settings' and
'repo_config_values' structures that are not tied to any
repository instance, we are back to depending on a set of global
variables. 😞

In any case, all of that has little to do with this series, I
suspect, unless we are redesigning these configurations and
settings in such a way that they are not necessarily tied to
any repository instance.  While I do not know the exact details,
I can imagine a hierarchical system where system- and
user-wide sets of setting values are known independently of any
repository, only to be overridden by per-repository settings
using a last-one-wins strategy at lookup time.