Re: [PATCH v3 3/4] config: clarify meaning of command line scoping

From: Matt Rogers <mattr94@gmail.com>
Date: Jan 18, 2020, 15:33 UTC
Message-ID: <CAOjrSZvm3yNH+moCJUdmJ7S2snD8MdULuBimWrvF8vNU0PVqLg@mail.gmail.com>
In-Reply-To: <xmqqwo9pdchx.fsf@gitster-ct.c.googlers.com>

> we have such a scope for one-shot settings and these three
> sources are already treated as the same class.
>

So this isn't technically correct, as before the final patch of this series we technically don't set the current_parsing_scope for those options. This doesn't actually affect anything though, because before then nothing actually checks the current_parsing_scope during such calls to git config. As such, it makes sense to me to keep that part of the commit message.

Show 17 quoted lines

> > This patch introduces
> > CONFIG_SCOPE_COMMAND to reflect this new idea, which also makes
> > CONFIG_SCOPE_CMDLINE redundant.
>
> The change in this commit is to rename CMDLINE to COMMAND.  That is
> what the proposed log message for this step must justify.
>
>         We internally use CONFIG_SCOPE_CMDLINE for the scope for the
>         configuration variables that come from "git -c VAR=VAL",
>         "git config --file=FILE" and "git config --blob=BLOB".  As
>         we are going to expose the scope names to end-users in the
>         next step, let's rethink the half-cryptic "cmdline" and
>         instead use a proper word "command" (the settings from three
>         sources in this scope are all in effect only during a single
>         invocation of a git command).
>
> or something like that.

I like this explanation much better so I'll roll that into the commit message.

Show 19 quoted lines

>
>
> > --- a/t/helper/test-config.c
> > +++ b/t/helper/test-config.c
> > @@ -48,8 +48,8 @@ static const char *scope_name(enum config_scope scope)
> >               return "repo";
> >       case CONFIG_SCOPE_WORKTREE:
> >               return "worktree";
> > -     case CONFIG_SCOPE_CMDLINE:
> > -             return "cmdline";
> > +     case CONFIG_SCOPE_COMMAND:
> > +             return "command";
>
> The only externally observable effect of this patch is this output
> string from test-tool and we are not breaking end-user experience,
> but I am not sure if this churn is worth it.  I dunno.
>
> In any case, the change to t1308 we saw in the previous step belongs
> to this step, I think.

Yeah, this was my bad...

-- 
Matthew Rogers