* [PATCH] config: add string mapping for enum config_scope
@ 2019-12-11 22:09 Emily Shaffer
2019-12-11 22:19 ` Junio C Hamano
0 siblings, 1 reply; 6+ messages in thread
From: Emily Shaffer @ 2019-12-11 22:09 UTC (permalink / raw)
To: git; +Cc: Emily Shaffer, Matthew Rogers, Philip Oakley
If a user is interacting with their config files primarily by the 'git
config' command, using the location flags (--global, --system, etc) then
they may be more interested to see the scope of the config file they are
editing, rather than the filepath.
Signed-off-by: Emily Shaffer <emilyshaffer@google.com>
---
Note: This commit has been cherry-picked out of the "configuration-based
hook management" topic, at
lore.kernel.org/git/20191210023335.49987-1-emilyshaffer@google.com
It turned out that I wanted to use it for git-bugreport as well - to
explain the origin of the configs we are printing in the bugreport,
without directly exposing the user's home directory path.
This seems to have similar work to https://github.com/gitgitgadget/git/pull/478
which I believe hasn't been mailed yet; but that change is targeted
towards the builtin config command, rather than the config library.
Since I wanted to use the library, I'm sending on my own now. Maybe
this commit will be useful to that change's author.
- Emily
config.c | 17 +++++++++++++++++
config.h | 1 +
2 files changed, 18 insertions(+)
diff --git a/config.c b/config.c
index e7052b3977..a20110e016 100644
--- a/config.c
+++ b/config.c
@@ -3312,6 +3312,23 @@ enum config_scope current_config_scope(void)
return current_parsing_scope;
}
+const char *config_scope_to_string(enum config_scope scope)
+{
+ switch (scope) {
+ case CONFIG_SCOPE_SYSTEM:
+ return _("system");
+ case CONFIG_SCOPE_GLOBAL:
+ return _("global");
+ case CONFIG_SCOPE_REPO:
+ return _("repo");
+ case CONFIG_SCOPE_CMDLINE:
+ return _("cmdline");
+ case CONFIG_SCOPE_UNKNOWN:
+ default:
+ return _("unknown");
+ }
+}
+
int lookup_config(const char **mapping, int nr_mapping, const char *var)
{
int i;
diff --git a/config.h b/config.h
index 91fd4c5e96..c8bf296dcc 100644
--- a/config.h
+++ b/config.h
@@ -303,6 +303,7 @@ enum config_scope {
};
enum config_scope current_config_scope(void);
+const char *config_scope_to_string(enum config_scope);
const char *current_config_origin_type(void);
const char *current_config_name(void);
--
2.24.0.525.g8f36a354ae-goog
^ permalink raw reply related [flat|nested] 6+ messages in thread* Re: [PATCH] config: add string mapping for enum config_scope
2019-12-11 22:09 [PATCH] config: add string mapping for enum config_scope Emily Shaffer
@ 2019-12-11 22:19 ` Junio C Hamano
2019-12-11 23:11 ` Emily Shaffer
0 siblings, 1 reply; 6+ messages in thread
From: Junio C Hamano @ 2019-12-11 22:19 UTC (permalink / raw)
To: Emily Shaffer; +Cc: git, Matthew Rogers, Philip Oakley
Emily Shaffer <emilyshaffer@google.com> writes:
> If a user is interacting with their config files primarily by the 'git
> config' command, using the location flags (--global, --system, etc) then
> they may be more interested to see the scope of the config file they are
> editing, rather than the filepath.
>
> Signed-off-by: Emily Shaffer <emilyshaffer@google.com>
> ---
> Note: This commit has been cherry-picked out of the "configuration-based
> hook management" topic, at
> lore.kernel.org/git/20191210023335.49987-1-emilyshaffer@google.com
>
> It turned out that I wanted to use it for git-bugreport as well - to
> explain the origin of the configs we are printing in the bugreport,
> without directly exposing the user's home directory path.
>
> This seems to have similar work to https://github.com/gitgitgadget/git/pull/478
> which I believe hasn't been mailed yet; but that change is targeted
> towards the builtin config command, rather than the config library.
> Since I wanted to use the library, I'm sending on my own now. Maybe
> this commit will be useful to that change's author.
One thing I wondered about this in the original version was if the
returned value should be localized. In the context of the original,
the --porcelain mode refused to give this information in its output,
so it was OK to always localize the returned value to satisify the
other caller who wanted end-user-facing output.
But as a more general helper, I am not sure if this is the most
useful way to implement it. Shouldn't the function rather return
the machine-readable tokens and allow callers to localize it as
needed with its own _() around the returned value? I dunno.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] config: add string mapping for enum config_scope
2019-12-11 22:19 ` Junio C Hamano
@ 2019-12-11 23:11 ` Emily Shaffer
2019-12-11 23:14 ` Matt Rogers
2019-12-11 23:25 ` Emily Shaffer
0 siblings, 2 replies; 6+ messages in thread
From: Emily Shaffer @ 2019-12-11 23:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Matthew Rogers, Philip Oakley
On Wed, Dec 11, 2019 at 02:19:57PM -0800, Junio C Hamano wrote:
> Emily Shaffer <emilyshaffer@google.com> writes:
>
> > If a user is interacting with their config files primarily by the 'git
> > config' command, using the location flags (--global, --system, etc) then
> > they may be more interested to see the scope of the config file they are
> > editing, rather than the filepath.
> >
> > Signed-off-by: Emily Shaffer <emilyshaffer@google.com>
> > ---
> > Note: This commit has been cherry-picked out of the "configuration-based
> > hook management" topic, at
> > lore.kernel.org/git/20191210023335.49987-1-emilyshaffer@google.com
> >
> > It turned out that I wanted to use it for git-bugreport as well - to
> > explain the origin of the configs we are printing in the bugreport,
> > without directly exposing the user's home directory path.
> >
> > This seems to have similar work to https://github.com/gitgitgadget/git/pull/478
> > which I believe hasn't been mailed yet; but that change is targeted
> > towards the builtin config command, rather than the config library.
> > Since I wanted to use the library, I'm sending on my own now. Maybe
> > this commit will be useful to that change's author.
>
> One thing I wondered about this in the original version was if the
> returned value should be localized. In the context of the original,
> the --porcelain mode refused to give this information in its output,
> so it was OK to always localize the returned value to satisify the
> other caller who wanted end-user-facing output.
>
> But as a more general helper, I am not sure if this is the most
> useful way to implement it. Shouldn't the function rather return
> the machine-readable tokens and allow callers to localize it as
> needed with its own _() around the returned value? I dunno.
>
Hm. I think that's a good point, and allows this helper to be used for
something silly like putting together a sample invocation to 'git
config' if desired. It's meant to mirror the scope given to 'git config'
- which makes me think that no, it shouldn't be localized, since the
argument isn't localized either.
Ok, I'll take the locale marker off.
- Emily
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] config: add string mapping for enum config_scope
2019-12-11 23:11 ` Emily Shaffer
@ 2019-12-11 23:14 ` Matt Rogers
2019-12-11 23:27 ` Emily Shaffer
2019-12-11 23:25 ` Emily Shaffer
1 sibling, 1 reply; 6+ messages in thread
From: Matt Rogers @ 2019-12-11 23:14 UTC (permalink / raw)
To: Emily Shaffer; +Cc: Junio C Hamano, git, Philip Oakley
Another thing I also want to point out is that outside of this
function... when git config is called with the --local, etc. the
config scope is not actually CONFIG_SCOPE_LOCAL but
CONFIG_SCOPE_UNKNOWN. This is because the config machinery pretty
much equates --local and --file=./.git/config as pretty much
equivalent (assuming ./.git is the actual repo directory location).
So just something to keep in mind.
On Wed, Dec 11, 2019 at 6:11 PM Emily Shaffer <emilyshaffer@google.com> wrote:
>
> On Wed, Dec 11, 2019 at 02:19:57PM -0800, Junio C Hamano wrote:
> > Emily Shaffer <emilyshaffer@google.com> writes:
> >
> > > If a user is interacting with their config files primarily by the 'git
> > > config' command, using the location flags (--global, --system, etc) then
> > > they may be more interested to see the scope of the config file they are
> > > editing, rather than the filepath.
> > >
> > > Signed-off-by: Emily Shaffer <emilyshaffer@google.com>
> > > ---
> > > Note: This commit has been cherry-picked out of the "configuration-based
> > > hook management" topic, at
> > > lore.kernel.org/git/20191210023335.49987-1-emilyshaffer@google.com
> > >
> > > It turned out that I wanted to use it for git-bugreport as well - to
> > > explain the origin of the configs we are printing in the bugreport,
> > > without directly exposing the user's home directory path.
> > >
> > > This seems to have similar work to https://github.com/gitgitgadget/git/pull/478
> > > which I believe hasn't been mailed yet; but that change is targeted
> > > towards the builtin config command, rather than the config library.
> > > Since I wanted to use the library, I'm sending on my own now. Maybe
> > > this commit will be useful to that change's author.
> >
> > One thing I wondered about this in the original version was if the
> > returned value should be localized. In the context of the original,
> > the --porcelain mode refused to give this information in its output,
> > so it was OK to always localize the returned value to satisify the
> > other caller who wanted end-user-facing output.
> >
> > But as a more general helper, I am not sure if this is the most
> > useful way to implement it. Shouldn't the function rather return
> > the machine-readable tokens and allow callers to localize it as
> > needed with its own _() around the returned value? I dunno.
> >
> Hm. I think that's a good point, and allows this helper to be used for
> something silly like putting together a sample invocation to 'git
> config' if desired. It's meant to mirror the scope given to 'git config'
> - which makes me think that no, it shouldn't be localized, since the
> argument isn't localized either.
>
> Ok, I'll take the locale marker off.
>
> - Emily
--
Matthew Rogers
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] config: add string mapping for enum config_scope
2019-12-11 23:14 ` Matt Rogers
@ 2019-12-11 23:27 ` Emily Shaffer
0 siblings, 0 replies; 6+ messages in thread
From: Emily Shaffer @ 2019-12-11 23:27 UTC (permalink / raw)
To: Matt Rogers; +Cc: Junio C Hamano, git, Philip Oakley
On Wed, Dec 11, 2019 at 06:14:44PM -0500, Matt Rogers wrote:
> Another thing I also want to point out is that outside of this
> function... when git config is called with the --local, etc. the
> config scope is not actually CONFIG_SCOPE_LOCAL but
> CONFIG_SCOPE_UNKNOWN. This is because the config machinery pretty
> much equates --local and --file=./.git/config as pretty much
> equivalent (assuming ./.git is the actual repo directory location).
> So just something to keep in mind.
Hm, that's interesting and sounds like a bug to me. But for this helper,
which is context independent, I don't think it should be addressed.
By the way, we're glad to have you contributing Matt - as a point of
order this list tends to prefer bottom-posting or inline replies.
Welcome!
- Emily
>
> On Wed, Dec 11, 2019 at 6:11 PM Emily Shaffer <emilyshaffer@google.com> wrote:
> >
> > On Wed, Dec 11, 2019 at 02:19:57PM -0800, Junio C Hamano wrote:
> > > Emily Shaffer <emilyshaffer@google.com> writes:
> > >
> > > > If a user is interacting with their config files primarily by the 'git
> > > > config' command, using the location flags (--global, --system, etc) then
> > > > they may be more interested to see the scope of the config file they are
> > > > editing, rather than the filepath.
> > > >
> > > > Signed-off-by: Emily Shaffer <emilyshaffer@google.com>
> > > > ---
> > > > Note: This commit has been cherry-picked out of the "configuration-based
> > > > hook management" topic, at
> > > > lore.kernel.org/git/20191210023335.49987-1-emilyshaffer@google.com
> > > >
> > > > It turned out that I wanted to use it for git-bugreport as well - to
> > > > explain the origin of the configs we are printing in the bugreport,
> > > > without directly exposing the user's home directory path.
> > > >
> > > > This seems to have similar work to https://github.com/gitgitgadget/git/pull/478
> > > > which I believe hasn't been mailed yet; but that change is targeted
> > > > towards the builtin config command, rather than the config library.
> > > > Since I wanted to use the library, I'm sending on my own now. Maybe
> > > > this commit will be useful to that change's author.
> > >
> > > One thing I wondered about this in the original version was if the
> > > returned value should be localized. In the context of the original,
> > > the --porcelain mode refused to give this information in its output,
> > > so it was OK to always localize the returned value to satisify the
> > > other caller who wanted end-user-facing output.
> > >
> > > But as a more general helper, I am not sure if this is the most
> > > useful way to implement it. Shouldn't the function rather return
> > > the machine-readable tokens and allow callers to localize it as
> > > needed with its own _() around the returned value? I dunno.
> > >
> > Hm. I think that's a good point, and allows this helper to be used for
> > something silly like putting together a sample invocation to 'git
> > config' if desired. It's meant to mirror the scope given to 'git config'
> > - which makes me think that no, it shouldn't be localized, since the
> > argument isn't localized either.
> >
> > Ok, I'll take the locale marker off.
> >
> > - Emily
>
>
>
> --
> Matthew Rogers
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] config: add string mapping for enum config_scope
2019-12-11 23:11 ` Emily Shaffer
2019-12-11 23:14 ` Matt Rogers
@ 2019-12-11 23:25 ` Emily Shaffer
1 sibling, 0 replies; 6+ messages in thread
From: Emily Shaffer @ 2019-12-11 23:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Matthew Rogers, Philip Oakley
On Wed, Dec 11, 2019 at 03:11:46PM -0800, Emily Shaffer wrote:
> On Wed, Dec 11, 2019 at 02:19:57PM -0800, Junio C Hamano wrote:
> > Emily Shaffer <emilyshaffer@google.com> writes:
> >
> > > If a user is interacting with their config files primarily by the 'git
> > > config' command, using the location flags (--global, --system, etc) then
> > > they may be more interested to see the scope of the config file they are
> > > editing, rather than the filepath.
> > >
> > > Signed-off-by: Emily Shaffer <emilyshaffer@google.com>
> > > ---
> > > Note: This commit has been cherry-picked out of the "configuration-based
> > > hook management" topic, at
> > > lore.kernel.org/git/20191210023335.49987-1-emilyshaffer@google.com
> > >
> > > It turned out that I wanted to use it for git-bugreport as well - to
> > > explain the origin of the configs we are printing in the bugreport,
> > > without directly exposing the user's home directory path.
> > >
> > > This seems to have similar work to https://github.com/gitgitgadget/git/pull/478
> > > which I believe hasn't been mailed yet; but that change is targeted
> > > towards the builtin config command, rather than the config library.
> > > Since I wanted to use the library, I'm sending on my own now. Maybe
> > > this commit will be useful to that change's author.
> >
> > One thing I wondered about this in the original version was if the
> > returned value should be localized. In the context of the original,
> > the --porcelain mode refused to give this information in its output,
> > so it was OK to always localize the returned value to satisify the
> > other caller who wanted end-user-facing output.
> >
> > But as a more general helper, I am not sure if this is the most
> > useful way to implement it. Shouldn't the function rather return
> > the machine-readable tokens and allow callers to localize it as
> > needed with its own _() around the returned value? I dunno.
> >
> Hm. I think that's a good point, and allows this helper to be used for
> something silly like putting together a sample invocation to 'git
> config' if desired. It's meant to mirror the scope given to 'git config'
> - which makes me think that no, it shouldn't be localized, since the
> argument isn't localized either.
Huh. One interesting piece is that the code talks about .git/config as
"repo" config, whereas 'git-config' talks about "--local". Does it make
sense to teach this enum stringifier that CONFIG_SCOPE_REPO means
"local"? I think CONFIG_SCOPE_REPO is used for "--worktree" too, so
perhaps it's better to let "repo" mean "local or worktree".
>
> Ok, I'll take the locale marker off.
>
> - Emily
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2019-12-11 23:27 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-12-11 22:09 [PATCH] config: add string mapping for enum config_scope Emily Shaffer
2019-12-11 22:19 ` Junio C Hamano
2019-12-11 23:11 ` Emily Shaffer
2019-12-11 23:14 ` Matt Rogers
2019-12-11 23:27 ` Emily Shaffer
2019-12-11 23:25 ` Emily Shaffer
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox