Bash completion of git-flow not works if try: $ git flow ... and not works if try; $ git-flow ... but if try this $ git flow ... completion will work Reproducible: Always
Please always add emerge --info to your bug reports.
Created attachment 400022 [details] emerge --info
This "problem" is still present as of dev-vcs/git-flow-1.8.0 and app-shells/bash-completion-2.1_p20141224. Due to the way bash-completion works now (dynamically loading needed completions) and "git-flow" being a separate completion script, there is no way for the dynamic loader to recognize the need of the git-flow completions. The phenomenon Oleg describes here is easily explained: $ git flow <TAB> Does not the correct completions, because "git-flow" hasn't been loaded yet. $ git-flow <TAB> # note the - instead of a whitespace Also does no correct completion, because this command doesn't define completions. BUT: The dynamic loader has finally loaded "git-flow" now, due to recognizing the command and loading the completion with the same name! $ git flow <TAB> Now the completions work as intended, since the correct script has been loaded! A simple workaround, without digging deep into the bash-completion internals, would be to simply symlink the git-flow script into the compatibility folder, like the old folks did: # ln -sv /usr/share/bash-completion/completions/git-flow /etc/bash_completion.d/ This way, the git-flow completions are always loaded regardless of being needed or not. Perhaps someone with more knowledge about the way bash-completion works nowadays can come up with a strategy to load such subcommands dynamically, too.
As I see it, the 'git' completion would have to have some extended support for loading sub-completions, i.e. recognize unknown 'flow' subcommand and try to load 'git-flow'.
Actually the git completion is rather smart anyway. If you type: $ git foo <TAB> Then git automatically uses the bash function _git_foo() if defined. The only problem is, how should git know whether _git_foo() is in another file which is not loaded yet? Is git even capable of finding that out? Or can we just say: If "git-foo" completion file exists in the same folder as "git", then source it before using _git_foo(). That would be one or two additional lines in the git completions file. That can be done via a patch that is applied in the ebuild.
What bash-completion itself does is: it checks whether the function exists, and loads the file if it doesn't. So you'd like to do the same -- check if function exists, if it doesn't, check if file exists and source it.
Where should we look for these subcommand completion files? Hardcoded in /usr/share/bash-completion/completions? Or is there an automatic handling of multiple directories, like custom completions in $HOME/.bash_completion.d or something like that? This approach may quickly escalate to re-implementing bash-completion into the git completion script. Is there a way for the main bash-completion loader to test if there is a file $command-$subcommand, even if the $command completion function already was assigned to $command?
Created attachment 406004 [details, diff] Patch to load completion files of git subcommands So for starters, how about the attached patch to the git completion file? It looks for a file called git-$subcommand in the same directory as the main git completion script and sources it if it exists, before attempting to use the related completion function.
Yeah, something like this. Though it'd be nice if you checked for the completion function existence (via declare -f) before sourcing the file again and again, and again... :) It would be good to cache 'file not found' case too.
Created attachment 406054 [details, diff] Patch to load completion files of git subcommands, v2 Okay, I re-arranged the lines a bit. The related files are sourced only if there is no function already present. That means, an additional completion file is sourced only once per terminal. You mentioned "caching of non-existent files", but actually I can't think of a proper way to do that. We could pass environment variables around like GIT_COMPL_NOT_FOUND="file1 file2" or writing those files to a tempfile that we would have to read each time. But is this really necessary in favor of a simple "test -f" that gets called on every try anyway? Furthermore I don't see bash_completion doing it either, so maybe they were caught by the exact same thoughts on how to pass those missing files around. I would consider this a "nice-to-have" but not exactly "vital" for the moment.
(In reply to Florian Gamböck from comment #10) > Created attachment 406054 [details, diff] [details, diff] > Patch to load completion files of git subcommands, v2 That patch work for me.
Why is this package stabilized when functionality is impaired?
The git completion is provided by dev-vcs/git, so there's nothing for bash-completion maintainers to do here. Reassigning.
Created attachment 526872 [details, diff] Patch to load completion files of git subcommands, v3 I changed the loading process by using the __load_completion function of bash-completion. This function automatically searches the correct completion script in the standard directories of bash-completion or fails silently if not found. Also, I finally posted the patch to the mailing list. https://public-inbox.org/git/20180408182552.26289-1-mail@floga.de/
This problem does no longer exist with >=dev-vcs/git-2.18. The completion for git-flow (and in fact completion scripts for every other non-canonical git subcommand) will be sourced automatically if needed by the completion script of git.
