Hi Junio,
Le 2024-02-10 à 12:15, Junio C Hamano a écrit :
> Philippe Blain <levraiphilippeblain@xxxxxxxxx> writes:
>
>>>> + __git_compute_config_vars
>>>> + local this_section="__git_first_level_config_vars_for_section_${section}"
>>>> + test -n "${!this_section}" ||
>>>> + printf -v "__git_first_level_config_vars_for_section_${section}" %s "$(echo "$__git_config_vars" | grep -E "^${section}\.[a-z]" | awk -F. '{print $2}')"
>>>> +}
>
> A silly question (primarily because I do not much use the indirect
> reference construct ${!name}). Does the assignment with printf need
> to spell out the long variable name with "_${section}"? Can it be
>
> printf -v "$this_section" ...
>
> instead, as we already have the short-hand for it?
No, unfortunately neither "$this_section" nor "${!this_section}"
work, so we must use the long name.
>
>> finds also others. I think the idea is to cache these lists to avoid
>> computing them everytime they are needed (probably most useful on Windows
>> where process creation is longer). I'll mention that in the
>> commit message.
>
> Yup, as long as the contents of the list stays stable (e.g., list of
> Git subcommands, list of options a Git subcommand takes, list of
> configuration variable names that do not have end-user customization
> part, etc.), it is a viable optimization technique. The available
> <slot> for color.branch.<slot> and color.diff.<slot> do not change
> (unless you talk about new version of Git adding support for more
> slots) and is a good idea to cache. remote.<name>.url takes its
> <name> component out of an unbound set of end-user controlled names,
> so unless we somehow have a method to invalidate cached values, the
> list can go stale as remotes are added and removed.
Indeed. Here I'm caching Git config variables, not any user-defined names,
so these are stable.
Thanks,
Philippe.
