Lea Wiemann <lewiemann@xxxxxxxxx> writes:
> diff --git a/t/test-lib.sh b/t/test-lib.sh
> index 163167c..4cd99af 100644
> --- a/t/test-lib.sh
> +++ b/t/test-lib.sh
> @@ -80,6 +80,8 @@ do
> debug=t; shift ;;
> -i|--i|--im|--imm|--imme|--immed|--immedi|--immedia|--immediat|--immediate)
> immediate=t; shift ;;
> + -l|--l|--lo|--lon|--long|--long-|--long-t|--long-te|--long-tes|--long-test|--long-tests)
> + export GIT_TEST_LONG=t; shift ;;
> -h|--h|--he|--hel|--help)
> help=t; shift ;;
> -v|--v|--ve|--ver|--verb|--verbo|--verbos|--verbose)
Hmm.
I am guessing that the reason why you do not unset GIT_TEST_LONG upfront
in the script is because the user can do:
$ cd t
$ GIT_TEST_LONG=t; export GIT_TEST_LONG
$ ./t9999-this-test.sh
$ ./t9999-that-test.sh
or even:
$ GIT_TEST_LONG=t make test
without having to say --long-tests from the command line that way. If
that is the case, however, I wonder if this --long-tests option is even
necessary.
Please do not get me wrong --- I am _not_ suggesting to unset (or set to
empty) GIT_TEST_LONG at the beginning of test-lib before command line
parsing. I do want the ability to run all the expensive tests with a
single command line retained, as I expect it would be useful before a
major release.
--
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
