Junio C Hamano wrote:
quoted text
> That is exactly what I mean.  I do not think bloating shell completion to
> enumerate what help topics there are when the user hits "git help <TAB>"
> is a good idea to begin with.  It is a maintenance nightmere for one
> thing, and it does not help non-bash users.
> 
> 	$ git help
> 	$ git help --all
> 
> are existing ways for you to get list of "command topics" that you can ask
> the help system about, but I do not see a way to ask "git-help, please
> tell me what topics that are not git-commands can I ask you about?", hence
> my suggestion to add "git help topics".
> 
> And if you based "git help <TAB>" completion on the output from such help
> subcommand, you would not have to maintain the list of topics yourself in
> the completion script, and I would not mind such a patch too much.

Gotcha.  A static list buried in git-completion.bash would be a maintenance
headache.  I can take a look at that some.

Would we also want to look at doing something similar with '--' option
completion, i.e. invoking the command with '-h' to get the usage and long
options, then building the completion list on that rather than the static
lists it uses now?  The one downside to that is that some completions
include trailing '=', which wouldn't be present in a usage list.

-- 
Marcus Griep
GPG Key ID: 0x5E968152
——
http://www.boohaunt.net
את.ψο´
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html