Junio C Hamano wrote: > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
