Nguyễn Thái Ngọc Duy <pclo...@gmail.com> writes:
> These commands can take options and use parse-options so it's quite
> easy to allow option completion. This does not pollute the command
> name completion though. "git <tab>" will show you the same set as
> before. This only kicks in when you type the correct command name.
>
> Some other builtin commands are not still added because either they
> don't use parse-options, or they are deprecated, or they are those
> -helper commands that are used to move some logic back in C for
> sh-based commands.
>
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclo...@gmail.com>
> ---
> contrib/completion/git-completion.bash | 276 +++++++++++++++++++++++++
> 1 file changed, 276 insertions(+)
Wow, just wow. It however looks a lot of boilerplates, e.g. looking
at these, we notice ...
> +_git_blame() {
> + case "$cur" in
> + --*)
> + __gitcomp_builtin blame
> + return
> + ;;
> + esac
> +}
> +
>
> +_git_cat_file() {
> + case "$cur" in
> + --*)
> + __gitcomp_builtin cat-file
> + return
> + ;;
> + esac
> +}
> +
> +_git_check_attr() {
> + case "$cur" in
> + --*)
> + __gitcomp_builtin check-attr
> + return
> + ;;
> + esac
> +}
... the only thing we need for the above three is a table that says
"use blame for blame, cat-file for cat_file, and check-attr for
check_attr".
And that pattern repeats throughout the patch. I wonder if we can
express the same a lot more concisely by updating the caller that
calls these command specific helpers?
