Junio,
>These are correct changes, but is unrelated noise in the context of
>the theme of the patch, no?
I think that's the case, would the recommended course of action be to
move these changes into its own commit?
>> + if (use_local_config || scope == CONFIG_SCOPE_REPO) {
>> + return "local";
>> + } else if (use_global_config || scope == CONFIG_SCOPE_GLOBAL) {
>> + return "global";
>> + } else if (use_system_config || scope == CONFIG_SCOPE_SYSTEM) {
>> + return "system";
>
>The above is slightly tricky; --global/--system/--local are made
>mutually exclusive in the higher level, so if any of them is set,
>we do not even need to look at the "scope" to tell what kind of
>source we are reading from.
So the way I structured these was to mirror the way other parts
of this file check if we should be doing a --local, etc. and mirrored
that here. This could definitely be cleaned up if we change the behavior
with how --local, etc. set the current_config_scope.
>> + } else if (given_config_source.use_stdin ||
>> + given_config_source.blob ||
>> + given_config_source.file ||
>> + scope == CONFIG_SCOPE_CMDLINE) {
>> + return "command line";
>
>I am not sure what the implication of saying "they came from the
>command line" when we read from the standard input or from a blob.
I agree with you here, I only put this as "command line"
because they came from a place that was ultimately fed in from
command line options (--file/--blob). I wouldn't have a problem with
calling them out as their own scope ("file", "blob", "stdin").
>> + } else {
>> + return "unknown";
>> + }
>> +}
>
>In any case, the need for such logic that says "scope might not say
>it is REPO, but when use_local_config is true, we are doing a local
>config" implies that "scope" parameter the caller of this function
>has is not set correctly when these options are used---would that be
>the real bug that needs fixing, rather than getting "worked around"
>with a code like this?
>
>It almost makes me point fingers at config.c::config_with_options()
>where config_source is inspected and git_config_from_*() helpers are
>called without setting the current_parsing_scope. Unlike these
>cases, when do_git_config_sequence() is called from that function,
>the scope is recorded in the variable before each standard config
>source file is opened and read. What would we be breaking if we
>taught the function to set the current_parsing_scope variable
>correctly even when reading from the config_source? That would
>certainly simplify this function quite a lot, but if the other parts
>of the codebase relies on the current behaviour, we cannot make such
>a change lightly.
>From what I can tell from a cursory glance. the only two clients of
this function are remote.c and upload-pack.c. The usecase for remote.c
mostly seems to be to determine the result of `remote_is_configured()`
which (more importantly) seems to be done when that iterates through
the relevant configuration options. Similarly for upload-pack.c.
I don't think it would be harmful for git config --local, etc. to set that
as we would normally intuit.
>> +static void show_config_scope(struct strbuf *buf)
>> +{
>> + const char term = end_nul ? '\0' : '\t';
>> + const char *scope = scope_to_string(current_config_scope());
>> +
>> + strbuf_addch(buf, '(');
>> + if (end_nul)
>> + strbuf_addstr(buf, N_(scope));
>> + else
>> + quote_c_style(scope, buf, NULL, 0);
>
>Isn't this overkill? I think this code was copied-and-pasted from
>the other function that needs to show an arbitrary end-user supplied
>data which is a pathname, so it makes perfect sense to use c-style
>quoting, but the token scope_to_string() returns is taken from a
>bounded set that doesn't require such quoting, no?
Yeah, I guess that is a copy+paste mistake. I don't think its
necessary since we control the input into this function, So I'll fix
that.
Philip,
>Doesn't this also need a man page update as well for adding the option
>to the synopsis.
>
>The commit message doesn't fully highlight that the config list will
>often be all the users config values, so each value will be
>disambiguated/identified as to it's origin.
I'm agreed on these. So I'll look to readjust that.
