Re: [PATCH 17/19] environment: move compression level into repo settings

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 15, 2025, 18:50 UTC
Message-ID: <xmqqy0spgufw.fsf@gitster.g>
In-Reply-To: <f6479d6a-32a4-4a49-a75c-589978cb9a57@gmail.com>

Phillip Wood <phillip.wood123@gmail.com> writes:

Show 8 quoted lines

> Indeed. My objection here was that we were delaying the parsing when
> it wasn't delayed before. Is it feasible to call
> prepare_repo_settings() in repo_config()? That would at least avoid
> the problem that moving config settings into `struct repo_settings`
> changes when the settings are parsed unless the command calls
> prepare_repo_settings() at start up. As far as I remember `git config`
> uses config_with_options() so that would not be adversely affected by
> such a change.

Excellent point.

Show 6 quoted lines

>> My dream would be that all configuration were to be defined in one
>> central place. The configuration should be typed, there should be
>> verification for each value configured by the user.
>
> Being able to verify config settings when they're set would be a great
> improvement but we're a long way from being able to do that.

Yes, and there always are end-user or third-party defined keys that are not known to us, and we cannot tell if an unknown variable is such a end-user defined one or a typo. I do not know if it is feasible to aim for that.

Show 6 quoted lines

>> But I very much feel like this is a pipe dream right now. We already
>> are
>> working on multiple fronts to modernize the code base, and I don't quite
>> feel like opening up _another_ large transformation right now.
>
> I agree with this

Agreed.

> I agree addressing all the shortcomings you've outlined would require
> a lot of refactoring. If we can find a way to avoid introducing
> anymore shortcomings as we migrate away from global variables that
> would be a good start.

;-).