From: <mattr94@gmail.com>
To: "'Philip Oakley'" <philipoakley@iee.email>,
"'Matthew Rogers via GitGitGadget'" <gitgitgadget@gmail.com>,
<git@vger.kernel.org>
Cc: "'Junio C Hamano'" <gitster@pobox.com>
Subject: RE: [PATCH 1/1] config: allow user to know scope of config options
Date: Wed, 18 Dec 2019 19:12:44 -0500 [thread overview]
Message-ID: <03b001d5b601$09b950e0$1d2bf2a0$@gmail.com> (raw)
In-Reply-To: <9a91caa0-72c3-3a38-3eb7-55a43537762e@iee.email>
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.
next prev parent reply other threads:[~2019-12-19 0:12 UTC|newest]
Thread overview: 98+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-18 1:11 [PATCH 0/1] config: allow user to know scope of config options Matthew Rogers via GitGitGadget
2019-12-18 1:11 ` [PATCH 1/1] " Matthew Rogers via GitGitGadget
2019-12-18 19:46 ` Junio C Hamano
2019-12-19 5:05 ` Jeff King
2019-12-19 17:51 ` Junio C Hamano
2019-12-18 22:45 ` Philip Oakley
2019-12-19 0:12 ` mattr94 [this message]
2019-12-19 17:56 ` Junio C Hamano
2019-12-20 22:58 ` Matt Rogers
2019-12-21 2:37 ` Junio C Hamano
2019-12-21 3:08 ` Matt Rogers
2019-12-21 23:47 ` Junio C Hamano
2020-01-09 10:16 ` [PATCH v2 0/4] " Matthew Rogers via GitGitGadget
2020-01-09 10:16 ` [PATCH v2 1/4] config: fix typo in variable name Matthew Rogers via GitGitGadget
2020-01-09 19:07 ` Junio C Hamano
2020-01-09 23:22 ` Matt Rogers
2020-01-10 11:55 ` Jeff King
2020-01-09 10:16 ` [PATCH v2 2/4] config: fix config scope enum Matthew Rogers via GitGitGadget
2020-01-09 19:06 ` Junio C Hamano
2020-01-09 23:29 ` Matt Rogers
2020-01-09 10:16 ` [PATCH v2 3/4] config: clarify meaning of command line scoping Matthew Rogers via GitGitGadget
2020-01-09 19:13 ` Junio C Hamano
2020-01-09 23:41 ` Matt Rogers
2020-01-09 10:16 ` [PATCH v2 4/4] config: add '--show-scope' to print the scope of a config value Matthew Rogers via GitGitGadget
2020-01-09 19:50 ` Junio C Hamano
2020-01-09 23:47 ` Matt Rogers
2020-01-17 15:31 ` [PATCH v3 0/4] config: allow user to know scope of config options Matthew Rogers via GitGitGadget
2020-01-17 15:31 ` [PATCH v3 1/4] config: fix typo in variable name Matthew Rogers via GitGitGadget
2020-01-17 15:31 ` [PATCH v3 2/4] config: refine config scope enum Matthew Rogers via GitGitGadget
2020-01-17 20:44 ` Junio C Hamano
2020-01-18 15:27 ` Matt Rogers
2020-01-18 18:09 ` Junio C Hamano
2020-01-17 15:31 ` [PATCH v3 3/4] config: clarify meaning of command line scoping Matthew Rogers via GitGitGadget
2020-01-17 21:00 ` Junio C Hamano
2020-01-18 15:33 ` Matt Rogers
2020-01-17 15:31 ` [PATCH v3 4/4] config: add '--show-scope' to print the scope of a config value Matthew Rogers via GitGitGadget
2020-01-17 21:21 ` Junio C Hamano
2020-01-17 21:26 ` Bert Wesarg
2020-01-18 15:42 ` Matt Rogers
2020-01-24 0:21 ` [PATCH v4 0/6] config: allow user to know scope of config options Matthew Rogers via GitGitGadget
2020-01-24 0:21 ` [PATCH v4 1/6] config: fix typo in variable name Matthew Rogers via GitGitGadget
2020-01-24 0:21 ` [PATCH v4 2/6] t1300: fix over-indented HERE-DOCs Matthew Rogers via GitGitGadget
2020-01-24 18:43 ` Junio C Hamano
2020-01-24 0:21 ` [PATCH v4 3/6] t1300: create custom config file without special characters Matthew Rogers via GitGitGadget
2020-01-24 18:45 ` Junio C Hamano
2020-01-24 0:21 ` [PATCH v4 4/6] config: split repo scope to local and worktree Matthew Rogers via GitGitGadget
2020-01-24 18:49 ` Junio C Hamano
2020-01-24 19:09 ` Junio C Hamano
2020-01-24 0:21 ` [PATCH v4 5/6] config: clarify meaning of command line scoping Matthew Rogers via GitGitGadget
2020-01-24 0:21 ` [PATCH v4 6/6] config: add '--show-scope' to print the scope of a config value Matthew Rogers via GitGitGadget
2020-01-24 19:18 ` Junio C Hamano
2020-01-24 20:22 ` Junio C Hamano
2020-01-24 20:49 ` Matt Rogers
2020-01-25 0:10 ` Junio C Hamano
2020-01-24 19:22 ` [PATCH v4 0/6] config: allow user to know scope of config options Junio C Hamano
2020-01-25 0:39 ` [PATCH v5 " Matthew Rogers via GitGitGadget
2020-01-25 0:39 ` [PATCH v5 1/6] config: fix typo in variable name Matthew Rogers via GitGitGadget
2020-01-25 0:39 ` [PATCH v5 2/6] t1300: fix over-indented HERE-DOCs Matthew Rogers via GitGitGadget
2020-01-25 0:39 ` [PATCH v5 3/6] t1300: create custom config file without special characters Matthew Rogers via GitGitGadget
2020-01-25 0:39 ` [PATCH v5 4/6] config: split repo scope to local and worktree Matthew Rogers via GitGitGadget
2020-01-27 23:09 ` Junio C Hamano
2020-01-25 0:39 ` [PATCH v5 5/6] config: clarify meaning of command line scoping Matthew Rogers via GitGitGadget
2020-01-25 0:39 ` [PATCH v5 6/6] config: add '--show-scope' to print the scope of a config value Matthew Rogers via GitGitGadget
2020-01-27 23:12 ` Junio C Hamano
2020-01-28 1:31 ` Matt Rogers
2020-01-29 3:34 ` [PATCH v6 0/6] config: allow user to know scope of config options Matthew Rogers via GitGitGadget
2020-01-29 3:34 ` [PATCH v6 1/6] config: fix typo in variable name Matthew Rogers via GitGitGadget
2020-01-29 3:34 ` [PATCH v6 2/6] t1300: fix over-indented HERE-DOCs Matthew Rogers via GitGitGadget
2020-01-29 3:34 ` [PATCH v6 3/6] t1300: create custom config file without special characters Matthew Rogers via GitGitGadget
2020-01-29 3:34 ` [PATCH v6 4/6] config: split repo scope to local and worktree Matthew Rogers via GitGitGadget
2020-01-29 3:34 ` [PATCH v6 5/6] config: clarify meaning of command line scoping Matthew Rogers via GitGitGadget
2020-01-29 3:34 ` [PATCH v6 6/6] config: add '--show-scope' to print the scope of a config value Matthew Rogers via GitGitGadget
2020-01-29 9:08 ` Bert Wesarg
2020-01-29 23:03 ` Matt Rogers
2020-02-05 19:01 ` Junio C Hamano
2020-01-29 5:29 ` [PATCH v6 0/6] config: allow user to know scope of config options Junio C Hamano
2020-02-10 0:30 ` [PATCH v7 00/10] " Matthew Rogers via GitGitGadget
2020-02-10 0:30 ` [PATCH v7 01/10] config: fix typo in variable name Matthew Rogers via GitGitGadget
2020-02-10 0:30 ` [PATCH v7 02/10] t1300: fix over-indented HERE-DOCs Matthew Rogers via GitGitGadget
2020-02-10 0:30 ` [PATCH v7 03/10] t1300: create custom config file without special characters Matthew Rogers via GitGitGadget
2020-02-10 0:30 ` [PATCH v7 04/10] config: make scope_name non-static and rename it Matthew Rogers via GitGitGadget
2020-02-10 18:02 ` Junio C Hamano
2020-02-10 21:25 ` Junio C Hamano
2020-02-11 0:30 ` Matt Rogers
2020-02-11 1:58 ` Emily Shaffer
2020-02-11 6:10 ` Junio C Hamano
2020-02-11 12:37 ` Matt Rogers
2020-02-10 0:30 ` [PATCH v7 05/10] config: split repo scope to local and worktree Matthew Rogers via GitGitGadget
2020-02-10 18:07 ` Junio C Hamano
2020-02-10 0:30 ` [PATCH v7 06/10] config: clarify meaning of command line scoping Matthew Rogers via GitGitGadget
2020-02-10 18:10 ` Junio C Hamano
2020-02-10 0:30 ` [PATCH v7 07/10] config: preserve scope in do_git_config_sequence Matthew Rogers via GitGitGadget
2020-02-10 18:11 ` Junio C Hamano
2020-02-10 0:30 ` [PATCH v7 08/10] config: teach git_config_source to remember its scope Matthew Rogers via GitGitGadget
2020-02-10 18:14 ` Junio C Hamano
2020-02-10 0:30 ` [PATCH v7 09/10] submodule-config: add subomdule config scope Matthew Rogers via GitGitGadget
2020-02-10 18:15 ` Junio C Hamano
2020-02-10 0:30 ` [PATCH v7 10/10] config: add '--show-scope' to print the scope of a config value Matthew Rogers via GitGitGadget
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='03b001d5b601$09b950e0$1d2bf2a0$@gmail.com' \
--to=mattr94@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=gitster@pobox.com \
--cc=philipoakley@iee.email \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).