Re: [PATCH 2/2] t6402: check exit status of ls-files

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

 



Eric Sunshine <sunshine@xxxxxxxxxxxxxx> writes:

> On Wed, Apr 21, 2021 at 12:55 PM Eric Sunshine <sunshine@xxxxxxxxxxxxxx> wrote:
>>     count_ls_files 5 -s &&
>>     count_ls_files 3 -u &&
>>     count_ls_files 1 -u one~HEAD &&
>>     ...
>>
>> The nice thing about having a helper function is that it can clean up
>> after itself by not leaving a new file lying around, thus you wouldn't
>> have to make adjustments to the expected number of untracked files (as
>> mentioned in the commit message). If this is the sort of thing which
>> comes up often enough (if there are more such cases beyond the two
>> scripts you changed in this series), then it might make sense to
>> promote the helper function to test-lib-functions.sh.
>
> The frequency with which this idiom crops up with commands beyond
> git-ls-files suggests the more general solution of supporting it
> directly in test-lib-functions.sh for any command. For instance:
>
>     test_cmd_line_count = 3 git ls-files -u &&
>
> Or, perhaps, a new mode of test_line_count():
>
>     test_line_count = 3 -c git ls-files -u &&

That looks nice on paper, but may be going too far.

We may want to count the lines in the error message, or we may want
to count the lines after filtering the output with pipe.

A test file that is dedicated to test ls-files with a file local
helper "count_ls_files" smells like a better place to stop, at least
to me.



[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