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

> On Tue, Jul 15, 2025 at 04:51:32PM +0100, Phillip Wood wrote:
> > On 15/07/2025 12:27, Patrick Steinhardt wrote:
> > > On Fri, Jul 11, 2025 at 11:55:27AM -0700, Junio C Hamano wrote:
> > > > Phillip Wood <phillip.wood123@gmail.com> writes:
> [snip]
> > >    - Not all configuration is equal. It may be perfectly fine to ignore
> > >      some configuration, but other configuration may very much be mission
> > >      critical. And whether or not configuration is important isn't really
> > >      something we can decide, as it will depend on the specific use case.
> > > 
> > > So I'm afraid that there just isn't a perfect solution here. Does it
> > > make sense to die due to a config key that isn't even used by a specific
> > > command? Maybe. And if not, which config keys _should_ make us die in
> > > case they are invalid?
> > > 
> > > The overall situation right now is a proper mess: we have config parsing
> > > cluttered everywhere, and the behaviour is just plain inconsistent. Some
> > > parsing is delayed, some isn't.
> > 
> > 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.
> 
> Hm, yeah, I think adding it to `repo_config()` might be a viable
> approach. I'll give it a try tomorrow and see what breaks :)