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.