Re: [PATCH v2] completion: adapt git-config(1) to complete subcommands
- From
Rubén Justo <rjusto@gmail.com>
- Date
- May 17, 2024, 16:27 UTC
- Message-ID
- <c48488d1-3135-493d-a9e8-2f787bdd2b4c@gmail.com>
- In-Reply-To
- <8d43dee33289969a5afbbf7635ac40b7312d8e19.1715926344.git.ps@pks.im>
On Fri, May 17, 2024 at 08:13:36AM +0200, Patrick Steinhardt wrote:
> ++ __git_resolve_builtins "config"
The __git_resolve_builtins() function executes "git config --git-completion-helper" and caches the result for future calls. And on return ...
> ++ > ++ subcommands="$___git_resolved_builtins"
... it populates the ___git_resolved_builtins variable with the result: the available subcommands for "git config".
> ++ subcommand="$(__git_find_subcommand "$subcommands")"
Then, we look for a subcommand among those returned, at ${words[__git_cmd_idx+1]}, where a possible command must reside.
Nicely done. This looks good to me.
I wonder, if we might consider the possibility of having "list" as a default command:
- subcommand="$(__git_find_subcommand "$subcommands")" + subcommand="$(__git_find_subcommand "$subcommands" list)"
These lines are only meant to express the idea, as other changes are also necessary and the documentation needs to be updated. Of course, it could be done in a future series.
I think that "git config -h" is an intuitive enough way to offer the help text and that using 'git config' as a shortcut for 'git config list' can be convenient.
By the way, having used '__git_find_subcommand' instead of '__git_find_on_cmdline' is reassuring when it comes to having a default subcommand :-)
Anyway, as I said, this series looks good to me. Thanks!