| Message ID | 20191211220933.48678-1-emilyshaffer@google.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | config: add string mapping for enum config_scope | expand |
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.
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
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
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
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
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);
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(+)