Re: [PATCH] config: add string mapping for enum config_scope

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Emily Shaffer <emilyshaffer@xxxxxxxxxx> 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@xxxxxxxxxx>
> ---
> Note: This commit has been cherry-picked out of the "configuration-based
> hook management" topic, at
> lore.kernel.org/git/20191210023335.49987-1-emilyshaffer@xxxxxxxxxx
>
> 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.




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux