Junio C Hamano <[email protected]> writes:
> Jeff King <[email protected]> writes:
>
>> This looks good to me.
>>
>> The only thing I might add is a test just to double-check that "git help
>> -a" is parsed correctly. Like:
>>
>> test_expect_success 'command completion works without test harness' '
>> GIT_TESTING_COMMAND_COMPLETION= run_completion "git bun" &&
>> grep "^bundle\$" out
>> '
>>
>> (we know we are running bash here, so the one-shot variable is OK to be
>> used with a function).
>
> I think you meant "^bundle $" there, but don't we have the same
> problem when there is an end-user subcommand "git bunny"?
>
> Ahh, ok, we show one element per line and just make sure "bundle"
> is there, and we do not care what other buns appear in the output.
>
> Will squash in, then.
Not so quick, though. The lower level "read from help -a" is only
run once and its output kept in a two-level cache hierarchy; we need
to reset both.
It starts to look a bit too intimately tied to the implementation of
what is being tested for my taste, though.
t/t9902-completion.sh | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/t/t9902-completion.sh b/t/t9902-completion.sh
index adc1372..bb6ee1a 100755
--- a/t/t9902-completion.sh
+++ b/t/t9902-completion.sh
@@ -286,4 +286,14 @@ test_expect_success 'send-email' '
test_completion "git send-email ma" "master "
'
+# This is better to be at the end, as it resets the state by tweaking
+# the internals.
+test_expect_success 'help -a read correctly by command list generator' '
+ __git_all_commands= &&
+ __git_porcelain_commands= &&
+ GIT_TESTING_COMMAND_COMPLETION= &&
+ run_completion "git bun" &&
+ grep "^bundle $" out
+'
+
test_done
--
1.8.1.1.525.gdace530
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
