On 3/3/2014 4:08 PM, Junio C Hamano wrote:
Ilya Bobyr <ilya.bo...@gmail.com> writes:
It might be that we are looking at different use cases, as you are
talking about whole test suits.
I do not think so.
I am trying to understand the use cases. And make sure we are talking
about the same ones.
I am not sure what are the use cases for GIT_SKIP_TESTS.
I think that while in it really nice when an interface allows to do new
things, the main use case (or use cases) should be as easy and obvious
in the first place.
If the target is the TDD use case I described, then it appears that a
user needs to do double negation. That is what concerns me.
I do not see anything prevents you from saying
GIT_SKIP_TESTS='t0000 !t0000.1 !t0000.4'
to specify test-pieces in individual tests so that you can run the
setup step (step .1) and the specific test (step .4) without running
two tests in between.
While it could be done, it looks less obvious than this:
GIT_TEST_ONLY='1 4' ./t0001-init.sh
What if we do what you proposed, but with GIT_RUN_TESTS?
If we want to have one interface, maybe, building on top of a "negation"
(GIT_SKIP_TESTS) is not very good.
At the same time, GIT_TEST_ONLY is also too specific for a generic
I could add GIT_RUN_TESTS and allow it to have all of the features, thus
making GIT_SKIP_TESTS a working but deprecated tool.
Running specific tests:
GIT_RUN_TESTS='1 3 7'
Negating some tests:
GIT_RUN_TESTS='!1 !3 !7'
The above would work exactly as you described but with one less level of
negation. Default is everything, unless at least one positive pattern
Later on range specification could added:
At least for now that would cover most use cases that I can think of
that look reasonable.
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