Re: [PATCH/RFC 0/2] Automate updating git-completion.bash a bit

[Duy Nguyen <pclouds@gmail.com>]

On Wed, Jan 17, 2018 at 7:51 AM, SZEDER Gábor <szeder.dev@gmail.com> wrote:
> On Tue, Jan 16, 2018 at 11:36 AM, Nguyễn Thái Ngọc Duy
> <pclouds@gmail.com> wrote:
>> I noticed --recurse-submodules was missing from git-grep complete
>> list. Then I found a couple more should be on the list as well and
>> many more in future may face the same faith. Perhaps this helps remedy
>> this situation?
>>
>> This lets us extract certain information from git commands and feed it
>> directly to git-completion.bash. Now long options by default will
>> be complete-able (which also means it's the reviewer's and coder's
>> responsibility to add "no complete" flag appropriately) but I think
>> the number of new dangerous options will be much fewer than
>> completeable ones.
>>
>> This is not really a new idea. Python has argcomplete that does more
>> or less the same thing.
>
> This has come up before for Git as well, see:
>
>   https://public-inbox.org/git/1334140165-24958-1-git-send-email-bebarino@gmail.com/T/#u

Thanks! I did search the archive but couldn't find this one.

>
> I see that your approach solves one of the shortcomings of those older
> patches, namely it makes possible to omit dangerous options from
> completion.  Great.
>
> I also see that you want to invoke git in a subshell every time the user
> attempts to complete an --option.  Not so great, at least for Windows
> users.  That older thread contains a few ideas about how to do it only
> once by lazy-initializing a variable for each command to hold its
> options.

Noted.

I see you also pointed out the problem with running commands like
"git-status" without a repository. I'll try to address this too if
possible (I'm thinking about making struct options[] available outside
cmd_*(); then we could handle it more like "git --version" which
always works)
-- 
Duy