On Wed, Jan 17, 2018 at 7:51 AM, SZEDER Gábor <szeder....@gmail.com> wrote: > On Tue, Jan 16, 2018 at 11:36 AM, Nguyễn Thái Ngọc Duy > <pclo...@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-bebar...@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
