RE: [PATCH 1/1] config: allow user to know scope of config options

[<mattr94@gmail.com>]

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.