On Tue, Jan 16, 2018 at 11:36 AM, Nguyễn Thái Ngọc Duy <pclouds@xxxxxxxxx> 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@xxxxxxxxx/T/#u 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. > This is just a proof of concept. More commands should be converted of > course if it's a good thing to do. > > Nguyễn Thái Ngọc Duy (2): > parse-options: support --git-completion-helper > git-completion: use --git-completion-helper > > builtin/grep.c | 13 +++++++----- > contrib/completion/git-completion.bash | 16 +-------------- > parse-options.c | 37 ++++++++++++++++++++++++++++++++++ > parse-options.h | 14 ++++++++----- > 4 files changed, 55 insertions(+), 25 deletions(-) > > -- > 2.15.1.600.g899a5f85c6 >
