From: Junio C Hamano <gitster@pobox.com>
To: Eric Sunshine <sunshine@sunshineco.com>
Cc: "Jeff King" <peff@peff.net>, "Git List" <git@vger.kernel.org>,
"Elijah Newren" <newren@gmail.com>,
"Shourya Shukla" <shouryashukla.oo@gmail.com>,
"Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Subject: Re: [PATCH v2] test_cmp: diagnose incorrect arguments
Date: Fri, 16 Oct 2020 11:36:53 -0700 [thread overview]
Message-ID: <xmqqzh4maugq.fsf@gitster.c.googlers.com> (raw)
In-Reply-To: <CAPig+cSU=1GcQuqZab+0Vff_A-JmD59wEc3RMr3wDojpgRYUuw@mail.gmail.com> (Eric Sunshine's message of "Thu, 15 Oct 2020 22:18:03 -0400")
Eric Sunshine <sunshine@sunshineco.com> writes:
> On Thu, Oct 15, 2020 at 8:17 PM Jeff King <peff@peff.net> wrote:
>> On Sun, Aug 09, 2020 at 01:42:09PM -0400, Eric Sunshine wrote:
>> > [...] Make it easier for test authors to discover such problems early
>> > by sanity-checking the arguments to test_cmp(). [...]
>>
>> This patch caused some interesting confusion for me today.
>> error: bug in the test script: test_cmp 'r2/.git/HEAD' missing
>> which was somewhat unhelpful (or at least less helpful than a regular
>> test failure). The test in question does this:
>> test_cmp r0/.git/HEAD r2/.git/HEAD &&
>> and expects to fail if an earlier step didn't correctly create r2. Is it
>> a bug or misuse of test_cmp for it to do so? I could see an argument
>> that it is, but I'm also not sure if there's a convenient alternative.
>
> I can see the argument going both ways as to whether it's a misuse of
> 'test_cmp'.
>
>> The best I could come up with is:
>>
>> test_path_is_file r2/.git/HEAD &&
>> test_cmp r0/.git/HEAD r2/.git/HEAD
>>
>> which isn't that great.
Hmph, I agree that the "both must be file" is a bit too eager and
ignores that "they must match, but the possible reasons they may not
include one of them may be missing" use case.
> Ævar ran into the same issue recently[1] and came up with the same
> workaround. Despite its good intention (trying to catch bugs in
> 'test_expect_failure' tests), this change[2] doesn't seem to have
> caught any genuine bugs (it wouldn't even have caught the bug which
> served as its inspiration[3]), but has nevertheless caused a couple
> hiccups already. As such, I would not be opposed to seeing the change
> reverted.
Sounds good. Anybody wants to do the honors?
next prev parent reply other threads:[~2020-10-16 18:37 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-09 6:08 [PATCH] test_cmp: diagnose incorrect arguments Eric Sunshine
2020-08-09 8:32 ` Shourya Shukla
2020-08-09 8:49 ` Eric Sunshine
2020-08-09 17:42 ` [PATCH v2] " Eric Sunshine
2020-08-09 19:12 ` Junio C Hamano
2020-08-09 19:34 ` Eric Sunshine
2020-08-10 15:22 ` Junio C Hamano
2020-08-11 18:32 ` Taylor Blau
2020-08-11 19:25 ` Eric Sunshine
2020-08-11 21:03 ` Taylor Blau
2020-08-12 15:37 ` Jeff King
2020-08-12 16:15 ` Eric Sunshine
2020-08-12 16:39 ` Eric Sunshine
2020-08-12 17:10 ` Jeff King
2020-10-16 0:17 ` Jeff King
2020-10-16 2:18 ` Eric Sunshine
2020-10-16 18:36 ` Junio C Hamano [this message]
2020-10-16 20:56 ` Junio C Hamano
2020-10-16 23:14 ` Junio C Hamano
2020-10-17 6:06 ` Eric Sunshine
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=xmqqzh4maugq.fsf@gitster.c.googlers.com \
--to=gitster@pobox.com \
--cc=avarab@gmail.com \
--cc=git@vger.kernel.org \
--cc=newren@gmail.com \
--cc=peff@peff.net \
--cc=shouryashukla.oo@gmail.com \
--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.
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.