Re: [PATCH 2/2] receive-pack: support push-to-checkout hook

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Dec 2, 2014, 13:25 UTC
Message-ID: <alpine.DEB.1.00.1412021421000.13845@s15462909.onlinehome-server.info>
In-Reply-To: <547DB894.4040609@drmicha.warpmail.net>

Hi Michael,

On Tue, 2 Dec 2014, Michael J Gruber wrote:

Show 18 quoted lines

> Johannes Schindelin schrieb am 02.12.2014 um 09:47:
> 
> > The only sad part is that the already huge test suite is enlarged by
> > yet another extensive set of test cases (and those tests might not
> > really need to be that extensive because they essentially only need to
> > make sure that the hook is run successfully *instead* of trying to
> > update the working directory, i.e. a simple 'touch yep' hook would
> > have been enough).  It starts to be painful to run the complete test
> > suite, not only on Windows (where this has been a multi-hour endeavor
> > for me for ages already). BuildHive (CloudBees' very kind offer of
> > Jenkins CI for Open Source, integrated conveniently with GitHub)
> > already takes over an hour to run the Git test suite – and BuildHive
> > runs on Linux, not Windows!
> 
> How about reusing the prerequisites feature for that? We could either
> mark the minimal tests, or mark the others similar to how we do with the
> (extra) expensive tests. Your config.mk would then determine which tests
> are executed.

In general, you are correct. And we already have the test_have_prereq EXPENSIVE precedent.

In this particular case, I question the value of the extent of the tests: the only thing we really need to test is that the new hook really overrides the default behavior, not all kinds of real-world simulations that *use* that behavior.

In other words, it is my opinion that the difference between the "touch yep" test I demonstrated and the test originally suggested is the amount of time it takes to run, not the extent to which the new code ist actually verified.

Ciao, Johannes