Jeff King <p...@peff.net> writes:

> On Tue, Apr 02, 2013 at 06:53:28PM +0200, Torsten Bögershausen wrote:
>
>> > I think the check for duplicate-numbers is the only one that does not
>> > make sense. 
>> []
>> Not sure about that, I send a suggestion of a patch in a minute.
>> Highlights:
>> 1) - rename the contrib test cases and assigns real TC numbers
>> 2) - Forward the numbers into the main "test Makefile"
>
> I'm not sure if this is a good idea or not.

If that's a polite way to say that this is not a good idea, I'd
agree for all the reasons you mentioned.

> It puts the
> contrib/remote-helpers into the same "number namespace" as the rest of
> the test scripts, and enforces uniqueness with test-lint-duplicates,
> when "make test" is run from contrib/remote-helpers. But people working
> on the main test scripts would not get any such check, and would happily
> break contrib/remote-helpers by adding duplicate test numbers.
>
> It makes sense to me to either:
>
>   1. Have the contrib/remote-helpers test live in their own test
>      namespace completely, with their own numbers and test-results, and
>      pull in relevant bits from the main test harness. We do this
>      already with contrib/subtree.  I suggested this when the tests
>      first appeared, but there was some argument, and I don't remember
>      the details.

This makes more sense than the alternative, given that contrib/
material is "optional" from the main tree's point of view, at least
to me.

Thanks.

>   2. Just integrate contrib test scripts into the main repository, but
>      leave them off by default. For example, add:
>
>        if test -z "$GIT_TEST_REMOTE_HELPERS"; then
>               skip_all="Remote helper tests disabled (define 
> GIT_TEST_REMOTE_HELPERS)"
>               test_done
>        fi
>
>      to the top of the scripts, and then set GIT_TEST_REMOTE_HELPERS
>      in contrib/remote-helpers/Makefile before chaining to the test
>      Makefile.
--
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