patchgit-remote: load config whenever create_symref() might be called

Currently, the calls to `create_symref()` do not honor the `core.logAllRefUpdates` nor the `user.{name,email}` configuration settings, and therefore write reflogs even when explicitly asked not to, and ignore the configured user identity.

This happens on `git remote add --fetch`, `git remote set-head`, and `git remote rename`: these are the three commands which may create a symbolic-ref for the remote's HEAD.

A call to `git_config(git_default_config, NULL);` for these three commands is enough to load the necessary configuration beforehand.

The call to `git_config()` was inserted right after command-line processing for these three commands. One might also decide to push it closer to the actual call to `create_symref()`, as it is not needed elsewhere, but it made more sense not to have it buried into nested `if` conditions.

Signed-off-by: Jérémie Detrey <Jeremie.Detrey@altu.fr>
---
 builtin/remote.c | 6 ++++++
 1 file changed, 6 insertions(+)

Jérémie Detrey <Jeremie.Detrey@altu.fr> writes:

Good problem description.

The usual way we structure the program start-up is do things in the following order:

 - have the hard-coded built-in default in the form of file-scope
   static variable definition with initial values; remote.c::value
   is an example that by default we are not verbose unless anybody
   else (below) says otherwise.

 - call git_config() to read and set configured defaults, which
   would override the hard-coded built-in default values.

 - call parse_options(), or other use some other means, to parse the
   command line options to further override the values that may have
   been set by reading the configuration files.

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?

Thanks.

Hi,

Thanks for the feedback!

Junio C Hamano:

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 :)

Cheers, Jérémie.

On Sat, Dec 26, 2020 at 5:31 PM Jérémie Detrey <Jeremie.Detrey@altu.fr> wrote:

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

Eric Sunshine <sunshine@sunshineco.com> writes:

OK, I guess.

Thanks.