Re: [PATCH 0/8] Resend of GIT_TEST_PROTOCOL_VERSION patches

From: Jeff King <peff@peff.net>
Date: Feb 6, 2019, 22:10 UTC
Message-ID: <20190206221008.GB15378@sigill.intra.peff.net>
In-Reply-To: <87ef8klh4g.fsf@evledraar.gmail.com>

On Wed, Feb 06, 2019 at 10:52:15PM +0100, Ævar Arnfjörð Bjarmason wrote:

Show 20 quoted lines

> > I wonder if it would be more obvious what's going on if we instead had a
> > prereq like:
> >
> >   test_expect_success !PROTO_V2 'ls-remote --symref' '
> >      ...
> >   '
> >
> > and just skipped those tests entirely (and in a way that appears in the
> > TAP output).
> >
> > I think it would also future-proof us a bit for v2 becoming the default
> > (i.e., when GIT_TEST_PROTOCOL_VERSION being blank does mean "use v2").
> >
> > I dunno. It probably doesn't matter all that much, so it may not be
> > worth going back and changing at this point. Just a thought.
> 
> So far we've had the convention that these GIT_TEST_* variables,
> e.g. the one for the commit graph, work the same way. Thus we guarantee
> that we get (in theory) 100% coverage even when running the tests in
> this special mode. I think it's better to keep it as-is.

But what's the point of that? Don't you always have to run the test suite _twice_, once with the special variable and once without? Otherwise, you are not testing one case or the other.

Or are you arguing that one might set many special variables in one go (to prefer running the suite only twice, instead of 2^N times). In which case we are better off running the test (as opposed to skipping it), as it might use one of the _other_ special variables besides GIT_TEST_PROTOCOL_VERSION.

I can buy that line of reasoning. It still doesn't cover all cases that a true 2^N test would, but that clearly isn't going to be practical.

-Peff