On Wed, Apr 25, 2018 at 3:46 PM, SZEDER Gábor <szeder.dev@xxxxxxxxx> wrote: > On Tue, Apr 24, 2018 at 6:17 PM, Duy Nguyen <pclouds@xxxxxxxxx> wrote: >> On Tue, Apr 24, 2018 at 6:12 PM, Duy Nguyen <pclouds@xxxxxxxxx> wrote: >>> git-completion.bash will be updated to ask git "give me the commands >>> in the mainporcelain, completable or external category". This also >>> addresses another thing that bugs me: I wanted an option to let me >>> complete all commands instead of just porcelain. This approach kinda >>> generalizes that and it would be easy to let the user choose what >>> category they want to complete. >> >> To complete this: there could also be yet another special category >> "custom", where --list-cmds=custom simply returns a list of commands >> specified in config file. With this the user can pick the "custom" >> category to have total control of what command shows up at "git <tab>" >> if they are not satisfied with the predefined categories. > > Note that config settings can be repository-specific, which might > cause surprises if the user sets a custom command list in one > repository's config file, but not (or a different one!) in others. > Then the list of completed commands will depend on where the user > happened to be when first hitting 'git <TAB>'. I think that is expected when the word "config file" is mentioned. It's no different than aliases, which could also be repo specific and affects completion. > Unless you forgo > caching the list of commands and run 'git --list-cmds=...' every time > the user hits 'git <TAB>', but that will add the overhead of fork()ing > a subshell and a git command. This is a good point. I'd rather forgo caching iff the "custom" strategy is used (technically we could still cache if we know the source if $HOME/.gitconfig or higher but it's not worth the effort). Just make it clear to the user that if they go with "custom" strategy then they may hit some performance hit. > Once upon a time I toyed with the idea of introducing environment > variables like $GIT_COMPLETION_EXCLUDE_COMMANDS and > $GIT_COMPLETION_INCLUDE_COMMANDS, to exclude and include commands from > 'git <TAB>'. I wanted to exclude 'git cherry', because I have never > ever used it but it's always in the way when I want to cherry-pick. > And I wanted to include 'git for-each-ref' back when I was running it > frequently while working on speeding up refs completion, but it > wouldn't have brought that much benefits, because I have a 'git > for-each-commit' script, too. > Never really pursued it, though, just patched the long list in > __git_list_porcelain_commands() in my git clone :) I'm tempted to support "delta custom list" (e.g. "+cherry-pick" in the config variable means "add that command on the existing list", or "-blame" means exclude it) but that's probably too much work. -- Duy
