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

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 7, 2026, 21:11 UTC
Message-ID: <xmqq1pc9eivn.fsf@gitster.g>
In-Reply-To: <anW7wHfUxYj9cj0P@pks.im>

Patrick Steinhardt <ps@pks.im> writes:

Show 25 quoted lines

> 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.