Am 9/26/2012 1:25, schrieb Junio C Hamano: > Johannes Sixt <j.sixt@xxxxxxxxxxxxx> writes: > >> Am 9/20/2012 21:46, schrieb Adam Spiers: >>> test_expect_success 'general options plus command' ' >>> - test_completion "git --version check" "checkout " && >>> - test_completion "git --paginate check" "checkout " && >>> - test_completion "git --git-dir=foo check" "checkout " && >>> - test_completion "git --bare check" "checkout " && >>> + test_completion "git --version checko" "checkout " && >>> + test_completion "git --paginate checko" "checkout " && >>> + test_completion "git --git-dir=foo checko" "checkout " && >>> + test_completion "git --bare checko" "checkout " && >>> ... >> >> I find this worrysome. Is check-ignore, being a debugging aid, so >> important that it must be autocompleted? > > The shell function __git_list_porcelain_commands in contrib/completion/ > starts from "git help -a" and filters plumbing commands and helpers > via a blacklist. At least, check-ignore needs to be added there. > > These days, we do not add random subcommands willy-nilly (I still > doubt if check-ignore needs to be a separate debugging command, or a > new mode of operation of ls-files or something), so the approach to > use a blacklist makes more sense. "help -a" is designed to show > whatever the users throw in their ~/bin (assuming that is on $PATH) > under git-whatever name, and we _do_ want to complete "git wh<TAB>" > to that custom command, so a whitelist-based solution is unwieldy to > construct. We already have 'git check-attr', but it is obviously not among the autocompleted commands, otherwise the above test would not have passed. IMO, 'git check-ignore' falls into the same category as 'git check-attr' with regard to completion. -- Hannes -- 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