Re: [PATCH 1/1] merge-recursive: avoid directory rename detection in recursive case

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Aug 06, 2019 at 02:16:25PM -0700, Elijah Newren wrote:

> > > +             test_i18ngrep ! CONFLICT out &&
> > > +             test_i18ngrep ! BUG: err &&
> >
> > The BUG is gone. But should it not use i18ngrep? BUG() isn't localized.
> 
> Technically, yes, you're right. However, this line's purpose isn't
> correctness of the test but documentation for the person reading the
> testcase about what it's real original purpose was; my real test was
> the "test_must_be_empty err" check I have below it, but I added this
> line just to document the intent better.  I kind of like the
> "CONFLICT" and "BUG" lines looking similar just so the reader of the
> testcase doesn't have to try to reason through why they are different,
> although I guess it does present the problem that more careful readers
> like yourself might do a double take.

I think it would be better to drop the grep for BUG entirely.

Not BUG()-ing should be something we implicitly assume for all commands,
and checking the exit code already covers that[1]. I don't think we
should be cluttering up every test, even ones that are in response to a
BUG(), with redundant checks. If you really want to document it further,
a comment can do that without incurring extra run-time overhead. But I
think in this case that your existing comments and commit message cover
it quite well.

-Peff

[1] There are cases where there's a crash in a sub-process, but in that
    case the failure should be surfaced in the way the test is written.
    It is here, and I'd argue that any case where it isn't probably
    ought to be rewritten (because you're missing not just BUG()s, but
    probably die()).



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux