From: Michael Haggerty <mhagger@alum.mit.edu>
To: Jeff King <peff@peff.net>
Cc: Junio C Hamano <gitster@pobox.com>, git@vger.kernel.org
Subject: Re: [PATCH] t/Makefile: retain cache t/.prove across prove runs
Date: Sat, 19 May 2012 16:54:33 +0200 [thread overview]
Message-ID: <4FB7B429.80805@alum.mit.edu> (raw)
In-Reply-To: <20120502160753.GA7193@sigill.intra.peff.net>
On 05/02/2012 06:07 PM, Jeff King wrote:
> On Wed, May 02, 2012 at 05:31:52PM +0200, mhagger@alum.mit.edu wrote:
>> prove(1) can write a summary of its test results and timings into a
>> cache file, t/.prove, then use this information during later runs for
>> various purposes. But deleting t/.prove after every test run defeats
>> this purpose. So do not delete t/.prove as part of "make
>> DEFAILT_TEST_TARGET=prove test". (Continue to delete the file on
>> "make clean".)
>
> Thanks. I had found some odd behaviors with putting "--state" into
> GIT_PROVE_OPTS when I first switched my setup to use prove, but I didn't
> investigate. I think this issue explained some of what I saw.
>
> Do note, though, that we only clean ".prove" on a successful run. So
> something like "--state=hot,save" will still see the cache from the last
> run if there were failures. However, the prove cache is meant to be kept
> across many runs, even successful ones, so I think your patch makes
> sense.
>
>> ---
>> prove(1) can be told to retain information about test runs, and to use
>> it for interesting purposes during future invocations. For example,
>> it can be told to run tests that failed during the last run:
>>
>> GIT_PROVE_OPTS = --state=failed,save
>
> I don't think this actually works, because we also feed all of the test
> scripts to prove on the command line. So it will run them all, both
> failed and successful.
>
> I'm not sure if it is worth solving for "make test". I suspect having
> that not test everything would be error prone (i.e., it's too easy to
> accidentally not run the full suite when you meant to, and unexpected
> regressions in other tests will go unnoticed). You can always run
> "prove" yourself from the command line, or we can add a new target to do
> a partial test (with other options set up properly).
I totally believe you that some of the variations that I listed in my
commentary don't work in the git context. I'm not a prove expert; I
just noticed that removing the .prove file is counterproductive and
breaks some other prove features. I also agree with you that it would
be dangerous to encourage partial testing and that it is therefore not a
priority to make the use case that you mentioned work in the git context.
I still think my patch makes sense. The error that Peff pointed out was
in my commentary, not in the patch itself or in the log message. Junio,
is there something else keeping you from applying this patch?
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
next prev parent reply other threads:[~2012-05-19 14:55 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-02 15:31 [PATCH] t/Makefile: retain cache t/.prove across prove runs mhagger
2012-05-02 16:07 ` Jeff King
2012-05-19 14:54 ` Michael Haggerty [this message]
2012-05-19 15:27 ` Jeff King
2012-05-20 21:18 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4FB7B429.80805@alum.mit.edu \
--to=mhagger@alum.mit.edu \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=peff@peff.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).