{"thread":{"id":"52435","subject":"[PATCH] config: add string mapping for enum config_scope","startedAt":"2019-12-11T22:09:41Z","lastAt":"2019-12-11T23:27:28Z","messageCount":6,"participants":["Emily Shaffer","Junio C Hamano","Matt Rogers"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"387985","messageId":"20191211220933.48678-1-emilyshaffer@google.com","threadId":"52435","inReplyTo":null,"subject":"[PATCH] config: add string mapping for enum config_scope","fromName":"Emily Shaffer","fromEmail":"emilyshaffer@google.com","sentAt":"2019-12-11T22:09:33Z","receivedAt":"2019-12-11T22:09:41Z","isPatch":true,"sender":{"key":"nasamuffin@google.com","avatar":"https://avatars.githubusercontent.com/u/1606826?v=4"},"body":"If a user is interacting with their config files primarily by the 'git\nconfig' command, using the location flags (--global, --system, etc) then\nthey may be more interested to see the scope of the config file they are\nediting, rather than the filepath.\n\nSigned-off-by: Emily Shaffer <emilyshaffer@google.com>\n---\nNote: This commit has been cherry-picked out of the \"configuration-based\nhook management\" topic, at\nlore.kernel.org/git/20191210023335.49987-1-emilyshaffer@google.com\n\nIt turned out that I wanted to use it for git-bugreport as well - to\nexplain the origin of the configs we are printing in the bugreport,\nwithout directly exposing the user's home directory path.\n\nThis seems to have similar work to https://github.com/gitgitgadget/git/pull/478\nwhich I believe hasn't been mailed yet; but that change is targeted\ntowards the builtin config command, rather than the config library.\nSince I wanted to use the library, I'm sending on my own now. Maybe\nthis commit will be useful to that change's author.\n\n - Emily\n\n config.c | 17 +++++++++++++++++\n config.h |  1 +\n 2 files changed, 18 insertions(+)\n\ndiff --git a/config.c b/config.c\nindex e7052b3977..a20110e016 100644\n--- a/config.c\n+++ b/config.c\n@@ -3312,6 +3312,23 @@ enum config_scope current_config_scope(void)\n \t\treturn current_parsing_scope;\n }\n \n+const char *config_scope_to_string(enum config_scope scope)\n+{\n+\tswitch (scope) {\n+\tcase CONFIG_SCOPE_SYSTEM:\n+\t\treturn _(\"system\");\n+\tcase CONFIG_SCOPE_GLOBAL:\n+\t\treturn _(\"global\");\n+\tcase CONFIG_SCOPE_REPO:\n+\t\treturn _(\"repo\");\n+\tcase CONFIG_SCOPE_CMDLINE:\n+\t\treturn _(\"cmdline\");\n+\tcase CONFIG_SCOPE_UNKNOWN:\n+\tdefault:\n+\t\treturn _(\"unknown\");\n+\t}\n+}\n+\n int lookup_config(const char **mapping, int nr_mapping, const char *var)\n {\n \tint i;\ndiff --git a/config.h b/config.h\nindex 91fd4c5e96..c8bf296dcc 100644\n--- a/config.h\n+++ b/config.h\n@@ -303,6 +303,7 @@ enum config_scope {\n };\n \n enum config_scope current_config_scope(void);\n+const char *config_scope_to_string(enum config_scope);\n const char *current_config_origin_type(void);\n const char *current_config_name(void);\n \n-- \n2.24.0.525.g8f36a354ae-goog\n\n"},{"id":"387986","messageId":"xmqqsglqmrn6.fsf@gitster-ct.c.googlers.com","threadId":"52435","inReplyTo":"20191211220933.48678-1-emilyshaffer@google.com","subject":"Re: [PATCH] config: add string mapping for enum config_scope","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2019-12-11T22:19:57Z","receivedAt":"2019-12-11T22:20:02Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Emily Shaffer <emilyshaffer@google.com> writes:\n\n> If a user is interacting with their config files primarily by the 'git\n> config' command, using the location flags (--global, --system, etc) then\n> they may be more interested to see the scope of the config file they are\n> editing, rather than the filepath.\n>\n> Signed-off-by: Emily Shaffer <emilyshaffer@google.com>\n> ---\n> Note: This commit has been cherry-picked out of the \"configuration-based\n> hook management\" topic, at\n> lore.kernel.org/git/20191210023335.49987-1-emilyshaffer@google.com\n>\n> It turned out that I wanted to use it for git-bugreport as well - to\n> explain the origin of the configs we are printing in the bugreport,\n> without directly exposing the user's home directory path.\n>\n> This seems to have similar work to https://github.com/gitgitgadget/git/pull/478\n> which I believe hasn't been mailed yet; but that change is targeted\n> towards the builtin config command, rather than the config library.\n> Since I wanted to use the library, I'm sending on my own now. Maybe\n> this commit will be useful to that change's author.\n\nOne thing I wondered about this in the original version was if the\nreturned value should be localized.  In the context of the original,\nthe --porcelain mode refused to give this information in its output,\nso it was OK to always localize the returned value to satisify the\nother caller who wanted end-user-facing output.\n\nBut as a more general helper, I am not sure if this is the most\nuseful way to implement it.  Shouldn't the function rather return\nthe machine-readable tokens and allow callers to localize it as\nneeded with its own _() around the returned value?  I dunno.\n\n"},{"id":"387989","messageId":"20191211231146.GC8464@google.com","threadId":"52435","inReplyTo":"xmqqsglqmrn6.fsf@gitster-ct.c.googlers.com","subject":"Re: [PATCH] config: add string mapping for enum config_scope","fromName":"Emily Shaffer","fromEmail":"emilyshaffer@google.com","sentAt":"2019-12-11T23:11:46Z","receivedAt":"2019-12-11T23:11:53Z","isPatch":true,"sender":{"key":"nasamuffin@google.com","avatar":"https://avatars.githubusercontent.com/u/1606826?v=4"},"body":"On Wed, Dec 11, 2019 at 02:19:57PM -0800, Junio C Hamano wrote:\n> Emily Shaffer <emilyshaffer@google.com> writes:\n> \n> > If a user is interacting with their config files primarily by the 'git\n> > config' command, using the location flags (--global, --system, etc) then\n> > they may be more interested to see the scope of the config file they are\n> > editing, rather than the filepath.\n> >\n> > Signed-off-by: Emily Shaffer <emilyshaffer@google.com>\n> > ---\n> > Note: This commit has been cherry-picked out of the \"configuration-based\n> > hook management\" topic, at\n> > lore.kernel.org/git/20191210023335.49987-1-emilyshaffer@google.com\n> >\n> > It turned out that I wanted to use it for git-bugreport as well - to\n> > explain the origin of the configs we are printing in the bugreport,\n> > without directly exposing the user's home directory path.\n> >\n> > This seems to have similar work to https://github.com/gitgitgadget/git/pull/478\n> > which I believe hasn't been mailed yet; but that change is targeted\n> > towards the builtin config command, rather than the config library.\n> > Since I wanted to use the library, I'm sending on my own now. Maybe\n> > this commit will be useful to that change's author.\n> \n> One thing I wondered about this in the original version was if the\n> returned value should be localized.  In the context of the original,\n> the --porcelain mode refused to give this information in its output,\n> so it was OK to always localize the returned value to satisify the\n> other caller who wanted end-user-facing output.\n> \n> But as a more general helper, I am not sure if this is the most\n> useful way to implement it.  Shouldn't the function rather return\n> the machine-readable tokens and allow callers to localize it as\n> needed with its own _() around the returned value?  I dunno.\n> \nHm. I think that's a good point, and allows this helper to be used for\nsomething silly like putting together a sample invocation to 'git\nconfig' if desired. It's meant to mirror the scope given to 'git config'\n- which makes me think that no, it shouldn't be localized, since the\nargument isn't localized either.\n\nOk, I'll take the locale marker off.\n\n - Emily\n"},{"id":"387990","messageId":"CAOjrSZuOOG=MbetP0RWYwLB+Zv5EZAHqkvkm0+WkBmSqxXiVTQ@mail.gmail.com","threadId":"52435","inReplyTo":"20191211231146.GC8464@google.com","subject":"Re: [PATCH] config: add string mapping for enum config_scope","fromName":"Matt Rogers","fromEmail":"mattr94@gmail.com","sentAt":"2019-12-11T23:14:44Z","receivedAt":"2019-12-11T23:14:59Z","isPatch":true,"sender":{"key":"mattr94@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5719846?v=4"},"body":"Another thing I also want to point out is that outside of this\nfunction... when git config is called with the --local, etc. the\nconfig scope is not actually CONFIG_SCOPE_LOCAL but\nCONFIG_SCOPE_UNKNOWN.  This is because the config machinery pretty\nmuch equates --local and --file=./.git/config as pretty much\nequivalent (assuming ./.git is the actual repo directory location).\nSo just something to keep in mind.\n\nOn Wed, Dec 11, 2019 at 6:11 PM Emily Shaffer <emilyshaffer@google.com> wrote:\n>\n> On Wed, Dec 11, 2019 at 02:19:57PM -0800, Junio C Hamano wrote:\n> > Emily Shaffer <emilyshaffer@google.com> writes:\n> >\n> > > If a user is interacting with their config files primarily by the 'git\n> > > config' command, using the location flags (--global, --system, etc) then\n> > > they may be more interested to see the scope of the config file they are\n> > > editing, rather than the filepath.\n> > >\n> > > Signed-off-by: Emily Shaffer <emilyshaffer@google.com>\n> > > ---\n> > > Note: This commit has been cherry-picked out of the \"configuration-based\n> > > hook management\" topic, at\n> > > lore.kernel.org/git/20191210023335.49987-1-emilyshaffer@google.com\n> > >\n> > > It turned out that I wanted to use it for git-bugreport as well - to\n> > > explain the origin of the configs we are printing in the bugreport,\n> > > without directly exposing the user's home directory path.\n> > >\n> > > This seems to have similar work to https://github.com/gitgitgadget/git/pull/478\n> > > which I believe hasn't been mailed yet; but that change is targeted\n> > > towards the builtin config command, rather than the config library.\n> > > Since I wanted to use the library, I'm sending on my own now. Maybe\n> > > this commit will be useful to that change's author.\n> >\n> > One thing I wondered about this in the original version was if the\n> > returned value should be localized.  In the context of the original,\n> > the --porcelain mode refused to give this information in its output,\n> > so it was OK to always localize the returned value to satisify the\n> > other caller who wanted end-user-facing output.\n> >\n> > But as a more general helper, I am not sure if this is the most\n> > useful way to implement it.  Shouldn't the function rather return\n> > the machine-readable tokens and allow callers to localize it as\n> > needed with its own _() around the returned value?  I dunno.\n> >\n> Hm. I think that's a good point, and allows this helper to be used for\n> something silly like putting together a sample invocation to 'git\n> config' if desired. It's meant to mirror the scope given to 'git config'\n> - which makes me think that no, it shouldn't be localized, since the\n> argument isn't localized either.\n>\n> Ok, I'll take the locale marker off.\n>\n>  - Emily\n\n\n\n-- \nMatthew Rogers\n"},{"id":"387992","messageId":"20191211232540.GE8464@google.com","threadId":"52435","inReplyTo":"20191211231146.GC8464@google.com","subject":"Re: [PATCH] config: add string mapping for enum config_scope","fromName":"Emily Shaffer","fromEmail":"emilyshaffer@google.com","sentAt":"2019-12-11T23:25:40Z","receivedAt":"2019-12-11T23:25:48Z","isPatch":true,"sender":{"key":"nasamuffin@google.com","avatar":"https://avatars.githubusercontent.com/u/1606826?v=4"},"body":"On Wed, Dec 11, 2019 at 03:11:46PM -0800, Emily Shaffer wrote:\n> On Wed, Dec 11, 2019 at 02:19:57PM -0800, Junio C Hamano wrote:\n> > Emily Shaffer <emilyshaffer@google.com> writes:\n> > \n> > > If a user is interacting with their config files primarily by the 'git\n> > > config' command, using the location flags (--global, --system, etc) then\n> > > they may be more interested to see the scope of the config file they are\n> > > editing, rather than the filepath.\n> > >\n> > > Signed-off-by: Emily Shaffer <emilyshaffer@google.com>\n> > > ---\n> > > Note: This commit has been cherry-picked out of the \"configuration-based\n> > > hook management\" topic, at\n> > > lore.kernel.org/git/20191210023335.49987-1-emilyshaffer@google.com\n> > >\n> > > It turned out that I wanted to use it for git-bugreport as well - to\n> > > explain the origin of the configs we are printing in the bugreport,\n> > > without directly exposing the user's home directory path.\n> > >\n> > > This seems to have similar work to https://github.com/gitgitgadget/git/pull/478\n> > > which I believe hasn't been mailed yet; but that change is targeted\n> > > towards the builtin config command, rather than the config library.\n> > > Since I wanted to use the library, I'm sending on my own now. Maybe\n> > > this commit will be useful to that change's author.\n> > \n> > One thing I wondered about this in the original version was if the\n> > returned value should be localized.  In the context of the original,\n> > the --porcelain mode refused to give this information in its output,\n> > so it was OK to always localize the returned value to satisify the\n> > other caller who wanted end-user-facing output.\n> > \n> > But as a more general helper, I am not sure if this is the most\n> > useful way to implement it.  Shouldn't the function rather return\n> > the machine-readable tokens and allow callers to localize it as\n> > needed with its own _() around the returned value?  I dunno.\n> > \n> Hm. I think that's a good point, and allows this helper to be used for\n> something silly like putting together a sample invocation to 'git\n> config' if desired. It's meant to mirror the scope given to 'git config'\n> - which makes me think that no, it shouldn't be localized, since the\n> argument isn't localized either.\n\nHuh. One interesting piece is that the code talks about .git/config as\n\"repo\" config, whereas 'git-config' talks about \"--local\". Does it make\nsense to teach this enum stringifier that CONFIG_SCOPE_REPO means\n\"local\"? I think CONFIG_SCOPE_REPO is used for \"--worktree\" too, so\nperhaps it's better to let \"repo\" mean \"local or worktree\".\n\n> \n> Ok, I'll take the locale marker off.\n> \n>  - Emily\n"},{"id":"387993","messageId":"20191211232721.GF8464@google.com","threadId":"52435","inReplyTo":"CAOjrSZuOOG=MbetP0RWYwLB+Zv5EZAHqkvkm0+WkBmSqxXiVTQ@mail.gmail.com","subject":"Re: [PATCH] config: add string mapping for enum config_scope","fromName":"Emily Shaffer","fromEmail":"emilyshaffer@google.com","sentAt":"2019-12-11T23:27:21Z","receivedAt":"2019-12-11T23:27:28Z","isPatch":true,"sender":{"key":"nasamuffin@google.com","avatar":"https://avatars.githubusercontent.com/u/1606826?v=4"},"body":"On Wed, Dec 11, 2019 at 06:14:44PM -0500, Matt Rogers wrote:\n> Another thing I also want to point out is that outside of this\n> function... when git config is called with the --local, etc. the\n> config scope is not actually CONFIG_SCOPE_LOCAL but\n> CONFIG_SCOPE_UNKNOWN.  This is because the config machinery pretty\n> much equates --local and --file=./.git/config as pretty much\n> equivalent (assuming ./.git is the actual repo directory location).\n> So just something to keep in mind.\n\nHm, that's interesting and sounds like a bug to me. But for this helper,\nwhich is context independent, I don't think it should be addressed.\n\nBy the way, we're glad to have you contributing Matt - as a point of\norder this list tends to prefer bottom-posting or inline replies.\nWelcome!\n\n - Emily\n\n> \n> On Wed, Dec 11, 2019 at 6:11 PM Emily Shaffer <emilyshaffer@google.com> wrote:\n> >\n> > On Wed, Dec 11, 2019 at 02:19:57PM -0800, Junio C Hamano wrote:\n> > > Emily Shaffer <emilyshaffer@google.com> writes:\n> > >\n> > > > If a user is interacting with their config files primarily by the 'git\n> > > > config' command, using the location flags (--global, --system, etc) then\n> > > > they may be more interested to see the scope of the config file they are\n> > > > editing, rather than the filepath.\n> > > >\n> > > > Signed-off-by: Emily Shaffer <emilyshaffer@google.com>\n> > > > ---\n> > > > Note: This commit has been cherry-picked out of the \"configuration-based\n> > > > hook management\" topic, at\n> > > > lore.kernel.org/git/20191210023335.49987-1-emilyshaffer@google.com\n> > > >\n> > > > It turned out that I wanted to use it for git-bugreport as well - to\n> > > > explain the origin of the configs we are printing in the bugreport,\n> > > > without directly exposing the user's home directory path.\n> > > >\n> > > > This seems to have similar work to https://github.com/gitgitgadget/git/pull/478\n> > > > which I believe hasn't been mailed yet; but that change is targeted\n> > > > towards the builtin config command, rather than the config library.\n> > > > Since I wanted to use the library, I'm sending on my own now. Maybe\n> > > > this commit will be useful to that change's author.\n> > >\n> > > One thing I wondered about this in the original version was if the\n> > > returned value should be localized.  In the context of the original,\n> > > the --porcelain mode refused to give this information in its output,\n> > > so it was OK to always localize the returned value to satisify the\n> > > other caller who wanted end-user-facing output.\n> > >\n> > > But as a more general helper, I am not sure if this is the most\n> > > useful way to implement it.  Shouldn't the function rather return\n> > > the machine-readable tokens and allow callers to localize it as\n> > > needed with its own _() around the returned value?  I dunno.\n> > >\n> > Hm. I think that's a good point, and allows this helper to be used for\n> > something silly like putting together a sample invocation to 'git\n> > config' if desired. It's meant to mirror the scope given to 'git config'\n> > - which makes me think that no, it shouldn't be localized, since the\n> > argument isn't localized either.\n> >\n> > Ok, I'll take the locale marker off.\n> >\n> >  - Emily\n> \n> \n> \n> -- \n> Matthew Rogers\n"}]}