On Sat, Dec 26, 2020 at 5:31 PM Jérémie Detrey <Jeremie.Detrey@xxxxxxx> wrote: > Junio C Hamano: > > My gut feeling says that the best place to call git_config() on > > git_default_config would actually be in cmd_remote(), immediately > > before we call parse_options() to parse the main options shared by > > all subcommands of "git remote". Is there a reason why codepaths > > other than the three you singled out should *not* be affected by the > > basic set of configuration variables? > > No, none that I can think of. I'll leave more knowledgeable people > than me confirm this, but if that's the way to go, I'll be happy to > submit a revised patch following your suggestion :) I took a quick look at builtin/remote.c. It appears that several of the subcommands already make their own calls to git_config(), each with its own special-purpose `config_fn_t` as argument. Jérémie's patch, which invokes git_config() for specific cases, therefore, is consistent with existing practice in that file. Taking the approach of calling git_config() once before parse_options() should be possible but would require more surgery. The end result after surgery likely would be more maintainable going forward, but the localized fixes his patch makes might be reasonable in the short term. (But I'm not an area expert, so don't take my word for it.)
