On 9/11/2020 2:25 PM, Sean Barag via GitGitGadget wrote: > From: Sean Barag <sean@xxxxxxxxx> > > While Junio's request [1] was to avoids the unusual "write config then > immediately read it" pattern that exists in `cmd_clone`, Johannes > mentioned that --template can write new config values that aren't > automatically included in the environment [2]. This requires a config > re-read after `init_db` is called. > > Moving the initial config up does allow settings from config to be > overwritten by ones provided via CLI options in a more natural way > though, so that part of Junio's suggestion remains. > > [1] https://lore.kernel.org/git/pull.710.git.1598456751674.gitgitgadget@xxxxxxxxx/ > [2] https://github.com/gitgitgadget/git/pull/727#issuecomment-689740195 > > Signed-off-by: Sean Barag <sean@xxxxxxxxx> > Thanks-to: Junio C Hamano <gitster@xxxxxxxxx> > Thanks-to: Johannes Schindelin <johannes.schindelin@xxxxxx> > --- > builtin/clone.c | 26 +++++++++++++++++++++++++- > 1 file changed, 25 insertions(+), 1 deletion(-) > > diff --git a/builtin/clone.c b/builtin/clone.c > index b087ee40c2..bf095815f0 100644 > --- a/builtin/clone.c > +++ b/builtin/clone.c > @@ -851,8 +851,21 @@ static int checkout(int submodule_progress) > return err; > } > > +static int git_clone_config(const char *k, const char *v, void *cb) > +{ > + return git_default_config(k, v, cb); > +} > + Introducing this no-op seems a bit premature, but as long as it makes your future patches cleaner, then it is appropriate. > static int write_one_config(const char *key, const char *value, void *data) > { > + /* > + * give git_config_default a chance to write config values back to the environment, since > + * git_config_set_multivar_gently only deals with config-file writes > + */ > + int apply_failed = git_default_config(key, value, data); However, you change this to git_clone_config() in patch 4. Perhaps use git_clone_config() here instead? Thanks, -Stolee
