From: Elijah Newren <newren@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: "SZEDER Gábor" <szeder.dev@gmail.com>,
"Git Mailing List" <git@vger.kernel.org>
Subject: Re: [PATCH 2/5] t6036, t6042: use test_line_count instead of wc -l
Date: Fri, 25 May 2018 17:44:24 -0700 [thread overview]
Message-ID: <CABPp-BEcTKaPPUOVqTRUAW+LBBySCK0dgx1J66hYB30yMasK_Q@mail.gmail.com> (raw)
In-Reply-To: <xmqqy3g8pm8g.fsf@gitster-ct.c.googlers.com>
On Thu, May 24, 2018 at 6:17 PM, Junio C Hamano <gitster@pobox.com> wrote:
> SZEDER Gábor <szeder.dev@gmail.com> writes:
>
>>> - test 2 = $(git ls-files -s | wc -l) &&
>>> - test 2 = $(git ls-files -u | wc -l) &&
>>> - test 2 = $(git ls-files -o | wc -l) &&
>>
>> Here 'git ls-files -o' should have listed two untracked files ...
>>
>>> + git ls-files -s >out &&
>>> + test_line_count = 2 out &&
>>> + git ls-files -u >out &&
>>> + test_line_count = 2 out &&
>>> + git ls-files -o >out &&
>>> + test_line_count = 3 out &&
>>
>> ... but now you expect it to list three. I was about to point out the
>> typo, but then noticed that you expect it to list one more untracked
>> file than before in all subsequent tests... now that can't be just a
>> typo, can it?
>>
>> Please mention in the commit message that when using an intermediate
>> file to store the output, 'git ls-files -o' will list that file, too,
>> that's why the number of expected untracked files had to be adjusted;
>> so future readers won't have to figure this out themselves.
>
> I'd expect that a reader of the commit who cares enough to bother to
> wonder by looking at the patch and seeing that 2 became 3 would know
> why already. And a reader of the resulting file would not know that
> the 3 used to be 2, and won't be helped by "we used to count to 2,
> now we have 'out' also counted" that much, especially in the commit
> log message. What would help the latter would be to name which
> three paths we expect to see in the comment (or test against the
> exact list of paths, instead of using test_line_count).
>
>> An alternative to consider would be to add a .gitignore file in the
>> initial commit to ignore 'out', then the number of untracked files
>> don't have to be adjusted.
>
> I think that is a preferred solution that we've used in ls-files and
> status tests successfully.
...except that if we add a .gitignore to each initial commit (we use
test_create_repo for nearly every test to keep them separable meaning
we'd have to do this many times), then four lines above we have to
adjust the number of expected tracked files. And, for it to work,
we'd have to add an --exclude-standard flag to ls-files -o.
I can make that change if you both want it, but it seems like it's
actually making it harder to follow the changes rather than easier.
next prev parent reply other threads:[~2018-05-26 0:44 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-24 7:04 [PATCH 0/5] Modernize some testcases for merge-recursive corner cases Elijah Newren
2018-05-24 7:04 ` [PATCH 1/5] t6036, t6042: use test_create_repo to keep tests independent Elijah Newren
2018-05-24 7:04 ` [PATCH 2/5] t6036, t6042: use test_line_count instead of wc -l Elijah Newren
2018-05-24 10:05 ` SZEDER Gábor
2018-05-24 10:36 ` SZEDER Gábor
2018-05-24 17:03 ` Elijah Newren
2018-05-25 1:17 ` Junio C Hamano
2018-05-26 0:44 ` Elijah Newren [this message]
2018-05-24 7:04 ` [PATCH 3/5] t6036, t6042: prefer test_path_is_file, test_path_is_missing Elijah Newren
2018-05-24 7:04 ` [PATCH 4/5] t6036, t6042: prefer test_cmp to sequences of test Elijah Newren
2018-05-24 7:04 ` [PATCH 5/5] t6036: prefer test_when_finished to manual cleanup in following test Elijah Newren
[not found] <CABPp-BEcTKaPPUOVqTRUAW+LBBySCK0dgx1J66hYB30yMasK_Q@mail.gmail.com/>
2018-05-26 1:09 ` [PATCH 2/5] t6036, t6042: use test_line_count instead of wc -l Elijah Newren
2018-05-26 23:58 ` 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=CABPp-BEcTKaPPUOVqTRUAW+LBBySCK0dgx1J66hYB30yMasK_Q@mail.gmail.com \
--to=newren@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=szeder.dev@gmail.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.
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).