Junio C Hamano <gits...@pobox.com> writes:

> Jeff King <p...@peff.net> 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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to