On Fri, Feb 9, 2018 at 12:02 PM, Nguyễn Thái Ngọc Duy <pclo...@gmail.com> wrote:
> diff --git a/contrib/completion/git-completion.bash
> b/contrib/completion/git-completion.bash
> index c7b8b37f19..60127daebf 100644
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -1835,7 +1835,7 @@ _git_notes ()
>
> case "$subcommand,$cur" in
> ,--*)
> - __gitcomp '--ref'
> + __gitcomp_builtin notes
> ;;
> ,*)
> case "$prev" in
Hmm, after this patch is applied, this part of _git_notes() looks like
this:
case "$subcommand,$cur" in
<skip>
,*)
case "$prev" in
--ref)
__git_complete_refs
;;
*)
__gitcomp "$subcommands --ref"
;;
esac
;;
Note that '--ref' option passed to __gitcomp() along with the
subcommands.
It would be great if that option could come from parse options as well,
but we can't rely on $__gitcomp_builtin_notes being already initialized
at this point and the current __gitcomp_builtin function tightly couples
initializing that variable and completing options.
It would be even greater, if all the subcommands could come from parse
options as well, but not sure how that would fit into parse options,
because subcommands are, well, not --options.
There are only a few commands with subcommands whose main command
accepts an --option, too; I could only find 'notes', 'remote', 'stash'
and 'submodule'. The latter two are scripts, and for 'remote' we don't
offer its '--verbose' option along with its subcommands, but perhaps we
should. Anyway, considering that there are only two such cases at the
moment, I think we could live with that two hard-coded options.
