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