From: "Torsten Bögershausen" <tboegi@web.de>
To: "Jeff King" <peff@peff.net>, "Torsten Bögershausen" <tboegi@web.de>
Cc: Michael J Gruber <git@drmicha.warpmail.net>,
git@vger.kernel.org, Junio C Hamano <gitster@pobox.com>
Subject: Re: [PATCHv2] add: ignore only ignored files
Date: Sat, 22 Nov 2014 22:20:10 +0100 [thread overview]
Message-ID: <5470FE0A.1030802@web.de> (raw)
In-Reply-To: <20141122191932.GA13340@peff.net>
On 2014-11-22 20.19, Jeff King wrote:
> On Sat, Nov 22, 2014 at 03:59:12PM +0100, Torsten Bögershausen wrote:
>
>>>> +test_expect_success 'error out when attempting to add ignored ones but add others' '
>>>> + touch a.if &&
>>>> + test_must_fail git add a.?? &&
>>>> + ! (git ls-files | grep "\\.ig") &&
>>>> + (git ls-files | grep a.if)
>>>> +'
>> [...]
>>
>> 2 small comments:
>> Why the escaped "\\.ig" and the unescaped "a.if" ?
>
> I agree that is inconsistent, and I don't see any reason for it.
>
>> The other question, this is a more general one, strikes me every time I see
>> ! grep
>>
>> Should we avoid it by writing "test_must_fail" instead of "!" ?
>
> No. The point of test_must_fail over "!" is to check that not only does
> the command fail, but it fails with a clean exit rather than a signal
> death. The general philosophy is that this is useful for git (which we
> are testing), and not for third-party tools that we are using to check
> our outputs. In other words, we do not expect grep to segfault, and do
> not need to bother checking it.
>
> I do not think there is a real _downside_ to using test_must_fail for
> grep, except that it is a bit more verbose.
We may burn CPU cycles
>
> And that describes the goal, of course; actual implementation has been
> less consistent. Possibly because I do not know that those instructions
> are written down anywhere.
There is a hint in test-lib-functions.sh, but a short notice in CodingGuidelines
could be useful, once there is an agreement about grep, which I think we have.
> We usually catch such things in review these
> days, but there are many inconsistent spots in the existing suite.
>
>> The following came into my mind when working on another grepy thing,
>> and it may be unnecessary clumsy:
>>
>> test_expect_success 'error out when attempting to add ignored ones but add others' '
>> touch a.if &&
>> test_must_fail git add a.?? &&
>> git ls-files >files.txt &&
>> test_must_fail grep a.ig files.txt >/dev/null &&
>> grep a.if files.txt >/dev/null &&
>> rm files.txt
>
> Right, my "allergic to pipes" was basically advocating using a tempfile.
> But as noted above, it should remain "! grep" here. And there is no need
> to redirect the output of grep, as the test suite does it already (in
> fact, it is preferable not to, because somebody debugging the test with
> "-v" will get more output).
>
> -Peff
I counted 19 "test_must_fail grep" under t/*sh, and 201 "! grep".
As a general rule for further review of shell scripts can we say ?
! git # incorrect, we don't capture e.g. segfaults of signal
test_must_fail grep # correct, but not preferred for new code
! grep # preferred for new code
test_must_fail git # correct
next prev parent reply other threads:[~2014-11-22 21:20 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-19 14:52 [RFD/PATCH] add: ignore only ignored files Michael J Gruber
2014-11-19 18:51 ` Junio C Hamano
2014-11-19 19:15 ` Jeff King
2014-11-19 21:43 ` Junio C Hamano
2014-11-20 9:42 ` Michael J Gruber
2014-11-20 15:56 ` Jeff King
2014-11-20 17:23 ` Junio C Hamano
2014-11-20 18:20 ` Jeff King
2014-11-21 15:39 ` Michael J Gruber
2014-11-21 16:08 ` [PATCHv2] " Michael J Gruber
2014-11-21 18:01 ` Jeff King
2014-11-22 14:59 ` Torsten Bögershausen
2014-11-22 19:19 ` Jeff King
2014-11-22 21:20 ` Torsten Bögershausen [this message]
2014-11-23 19:50 ` Jeff King
2014-11-23 18:10 ` Junio C Hamano
2014-11-23 19:46 ` Jeff King
2014-11-24 17:41 ` Junio C Hamano
2014-11-24 20:22 ` Torsten Bögershausen
2014-11-25 3:57 ` Jeff King
2014-11-24 10:29 ` Michael J Gruber
2014-11-24 10:23 ` Michael J Gruber
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=5470FE0A.1030802@web.de \
--to=tboegi@web.de \
--cc=git@drmicha.warpmail.net \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.