Re: [PATCH v2 14/14] Add git-check-ignore sub-command

2 messages, 2 authors, 2016-06-15 · open the first message on its own page

Re: [PATCH v2 14/14] Add git-check-ignore sub-command

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:54:52

Johannes Sixt [off-list ref] writes:
Am 9/20/2012 21:46, schrieb Adam Spiers:
quoted
 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.

Re: [PATCH v2 14/14] Add git-check-ignore sub-command

From: Johannes Sixt <hidden>
Date: 2016-06-15 22:54:52

Am 9/26/2012 1:25, schrieb Junio C Hamano:
Johannes Sixt [off-list ref] writes:
quoted
Am 9/20/2012 21:46, schrieb Adam Spiers:
quoted
 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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help