Re: [PATCH v3 42/42] git-completion.bash: add GIT_COMPLETION_OPTIONS=all config
- From
Duy Nguyen <pclouds@gmail.com>
- Date
- Feb 12, 2018, 00:34 UTC
- Message-ID
- <CACsJy8BoPxbt=hqAd9fS7MLiF33FVtAk0=Fr_q7UgYy1YvEg0w@mail.gmail.com>
- In-Reply-To
- <CAPig+cT63UnZ1qLKc-Rk4k0ixL93ywd-i6AFH3mFJOWq2QpuBQ@mail.gmail.com>
On Sun, Feb 11, 2018 at 8:59 AM, Eric Sunshine <sunshine@sunshineco.com> wrote:
Show 43 quoted lines
> On Fri, Feb 9, 2018 at 6:02 AM, Nguyễn Thái Ngọc Duy <pclouds@gmail.com> wrote:
>> By default, some option names (mostly --force, scripting related or for
>> internal use) are not completable for various reasons. When
>> GIT_COMPLETION_OPTIONS is set to all, all options (except hidden ones)
>> are completable.
>>
>> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
>> ---
>> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
>> @@ -36,6 +36,10 @@
>> +#
>> +# GIT_COMPLETION_OPTIONS
>> +#
>> +# When set to "all", complete all possible options
>> @@ -303,7 +307,7 @@ __gitcomp_builtin ()
>> if [ -z "$options" ]; then
>> # leading and trailing spaces are significant to make
>> # option removal work correctly.
>> - options=" $(__git ${cmd/_/ } --git-completion-helper) $incl "
>> + options=" $(__git ${cmd/_/ } --git-completion-helper=$GIT_COMPLETION_OPTIONS) $incl "
>
> This approach is rather different from what I had envisioned. Rather
> than asking --git-completion-helper to do the filtering, my thought
> was that it should unconditionally dump _all_ options but annotate
> them, and then git-completion.bash can filter however it sees fit. For
> instance, --git-completion-helper might annotate "dangerous" options
> with a "!" ("!--force" or "--force!" or "--force:!" or whatever).
>
> The benefit of this approach is that it more easily supports future
> enhancements. For instance, options which only make sense in certain
> contexts could be annotated to indicate such. An example are the
> --continue, --abort, --skip options for git-rebase which only make
> sense when a rebase session is active. One could imagine these options
> being annotated something like this:
>
> --abort:rebasing
> --continue:rebasing
> --skip:rebasing
>
> where git-completion.bash understands the "rebasing" annotation as
> meaning that these options only make sense when "rebase-apply" is
> present. (In fact, the annotation could be more expressive, such as
> "--abort:exists(rebase-apply)", but that might be overkill.)I agree. I went a bit off track with this ...=all. But yes some form of annotation will be needed long term to describe these options in details. We haven't gotten the annotation in struct option[] to this level yet, it's a bit hard to see what will be needed here. Let's drop 42/42 for now. I will study git-completion.bash more to see what it needs and revisit this at some point in future.
-- Duy