Phillip Wood <phillip.wood123@xxxxxxxxx> writes: > 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. >> 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. >> 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. ;-).
