On Wed, Mar 21, 2018 at 9:59 PM, Junio C Hamano <gits...@pobox.com> wrote:
> 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?
>
Yeah. I almost went to just generate and eval these functions. But we
still need to keep a list of "bultin with --git-completion-helper"
support somewhere, and people may want to complete arguments without
double dashes (e.g. read-tree should take a ref...) which can't be
helped by --git-completion-helper.
--
Duy
