On Wed, Feb 14, 2018 at 10:15 PM, SZEDER Gábor <szeder.dev@xxxxxxxxx> wrote: > On Fri, Feb 9, 2018 at 12:02 PM, Nguyễn Thái Ngọc Duy <pclouds@xxxxxxxxx> 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, Yeah. This is where Eric's option annotation thingy comes in very handy. If we can tell git-completion.bash that "--ref takes a ref", then we can do __git_complete_refs automatically. I'm not so sure how to fit all things together yet. Just like you said below __gitcomp_builtin is very much completing options, not values. Worst case scenario, --git-completion-helper could generate the whole "case" block to be eval'd here, but that also means non-bash completion is left out. So I'm not going to do anything about this yet. Not until I study some more (and your notes here are very helpful) > 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. -- Duy
