Re: [PATCH v2 01/41] parse-options: support --git-completion-helper

On Thu, Feb 1, 2018 at 5:21 AM, Duy Nguyen [off-list ref] wrote:

On Thu, Feb 1, 2018 at 4:54 PM, Eric Sunshine [off-list ref] wrote:

quoted

I don't see that as convincing argument for two classes of "no
complete". Since git-completion.bash already special-cases
rebase/am/cherry-pick for --continue|--abort|--skip, it is not far
fetched that that special-case treatment can be extended slightly to
also filter out those three options from the list returned by
--git-completion-helper.

I agree that is possible, but it's a bit tricky to do the filtering
right in bash (all options are sent back as one line instead of one
per line, which is easier to process by command line tools).

Perhaps I'm missing something, but wouldn't filtering out those
options directly in Bash require only this?

    % x='--foo --bar --snoo'
    % echo ${x/--bar}
    --foo --snoo

On top of  that, I think we want git-completion.bash to be fast, the
more commands we execute there, the unhappier Windows users are. It is
too possible to do this kind of filtering just once, before caching.
It does not fit well to how I designed __gitcomp_builtin so I need to
sit back and see how to sort that out.

The filtering as illustrated above using builtin Bash functionality
seems unlikely to be a source of noticeable slow down on Windows.

And, if you're concerned about it not fitting the design of
__gitcomp_builtin, it's almost certainly cheap enough to do the
filtering each time its needed rather than worrying about caching the
filtered list. (It's hard to imagine anyone noticing a slow down of
three extra ${x/} substitutions.)