From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: Eric Sunshine <sunshine@sunshineco.com>,
Jonathan Nieder <jrnieder@gmail.com>,
Git List <git@vger.kernel.org>,
Michael Haggerty <mhagger@alum.mit.edu>
Subject: Re: test &&-chain lint
Date: Thu, 19 Mar 2015 23:51:26 -0700 [thread overview]
Message-ID: <xmqqd244go0h.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <20150320022532.GA5502@peff.net> (Jeff King's message of "Thu, 19 Mar 2015 22:25:32 -0400")
Jeff King <peff@peff.net> writes:
> [+cc Jonathan, whose patch I apparently subconsciously copied]
>
> On Thu, Mar 19, 2015 at 10:08:51PM -0400, Jeff King wrote:
>
>> diff --git a/t/test-lib.sh b/t/test-lib.sh
>> index c096778..02a03d5 100644
>> --- a/t/test-lib.sh
>> +++ b/t/test-lib.sh
>> @@ -524,6 +524,21 @@ test_eval_ () {
>> test_run_ () {
>> test_cleanup=:
>> expecting_failure=$2
>> +
>> + if test -n "$GIT_TEST_CHAIN_LINT"; then
>> + # 117 is unlikely to match the exit code of
>> + # another part of the chain
>> + test_eval_ "(exit 117) && $1"
>> + if test "$?" != 117; then
>> + # all bets are off for continuing with other tests;
>> + # we expected none of the rest of the test commands to
>> + # run, but at least some did. Who knows what weird
>> + # state we're in? Just bail, and the user can diagnose
>> + # by running in --verbose mode
>> + error "bug in the test script: broken &&-chain"
>> + fi
>> + fi
>> +
>> setup_malloc_check
>> test_eval_ "$1"
>> eval_ret=$?
>>
>> This turns up an appalling number of failures, but AFAICT they are all
>> "real" in the sense that the &&-chains are broken. In some cases these
>> are real, but in others the tests are of an older style where they did
>> not expect some early commands to fail (and we would catch their bogus
>> output if they did). E.g., in the patch below, I think the first one is
>> a real potential bug, and the other two are mostly noise. I do not mind
>> setting a rule and fixing all of them, though.
>>
>> I seem to recall people looked at doing this sort of lint a while ago,
>> but we never ended up committing anything. I wonder if it was because of
>> all of these "false positives".
>
> This turns out to be rather annoying to grep for in the list archives,
> but I found at least one discussion:
>
> http://article.gmane.org/gmane.comp.version-control.git/235913
>
> I don't know why we didn't follow it up then. Perhaps because the patch
> there (which is rather similar to what I have above) was not
> conditional, so whole chunks of the test suite needed fixing. There are
> enough problems that we would probably want to do this conditionally,
> fix them over time, and then finally flip the feature on by default.
Hmmm, they do look similar and unfamiliar ;-) It happened while I
was offline, it seems.
Thanks for working on this---I think test-chain-lint should become
one of the pre-acceptance test on my end when it gets applied.
next prev parent reply other threads:[~2015-03-20 6:51 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-17 7:27 [PATCH 0/5] not making corruption worse Jeff King
2015-03-17 7:28 ` [PATCH 1/5] t5312: test object deletion code paths in a corrupted repository Jeff King
2015-03-17 18:34 ` Johannes Sixt
2015-03-17 18:55 ` Jeff King
2015-03-18 20:42 ` Johannes Sixt
2015-03-19 20:04 ` Junio C Hamano
2015-03-19 20:51 ` Jeff King
2015-03-19 21:23 ` Junio C Hamano
2015-03-19 21:47 ` Jeff King
2015-03-19 21:49 ` Junio C Hamano
2015-03-19 21:52 ` Jeff King
2015-03-20 1:16 ` Eric Sunshine
2015-03-20 1:32 ` Jeff King
2015-03-20 1:37 ` Eric Sunshine
2015-03-20 2:08 ` test &&-chain lint (was: [PATCH 1/5] t5312: test object deletion code paths in a corrupted repository) Jeff King
2015-03-20 2:25 ` Jeff King
2015-03-20 5:10 ` Jeff King
2015-03-20 7:18 ` Eric Sunshine
2015-03-20 6:51 ` Junio C Hamano [this message]
2015-03-20 17:04 ` test &&-chain lint Junio C Hamano
2015-03-20 17:24 ` Jeff King
2015-03-20 17:34 ` Junio C Hamano
2015-03-20 17:59 ` Jeff King
2015-03-17 7:29 ` [PATCH 2/5] refs: introduce a "ref paranoia" flag Jeff King
2015-03-19 20:13 ` Junio C Hamano
2015-03-19 21:00 ` Jeff King
2015-03-19 21:31 ` Junio C Hamano
2015-03-19 21:51 ` Jeff King
2015-03-17 7:30 ` [PATCH 3/5] prune: turn on ref_paranoia flag Jeff King
2015-03-17 7:31 ` [PATCH 4/5] repack: turn on "ref paranoia" when doing a destructive repack Jeff King
2015-03-17 7:31 ` [PATCH 5/5] refs.c: drop curate_packed_refs Jeff King
2015-03-20 1:27 ` Eric Sunshine
2015-03-17 7:37 ` [PATCH 0/5] not making corruption worse Jeff King
2015-03-17 22:54 ` Junio C Hamano
2015-03-18 10:21 ` Jeff King
2015-03-20 18:42 ` [PATCH v2 " Jeff King
2015-03-20 18:43 ` [PATCH v2 1/5] t5312: test object deletion code paths in a corrupted repository Jeff King
2015-03-20 18:43 ` [PATCH v2 2/5] refs: introduce a "ref paranoia" flag Jeff King
2015-03-20 18:43 ` [PATCH v2 3/5] prune: turn on ref_paranoia flag Jeff King
2015-03-20 18:43 ` [PATCH v2 4/5] repack: turn on "ref paranoia" when doing a destructive repack Jeff King
2015-03-20 18:43 ` [PATCH v2 5/5] refs.c: drop curate_packed_refs Jeff King
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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqd244go0h.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=jrnieder@gmail.com \
--cc=mhagger@alum.mit.edu \
--cc=peff@peff.net \
--cc=sunshine@sunshineco.com \
/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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
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 read-only IMAP folder(s) and NNTP newsgroup(s).