From: Eric Wong <e@80x24.org>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH v2 2/2] t1006: ensure cat-file info isn't buffered by default
Date: Wed, 19 Jun 2024 17:56:33 +0000 [thread overview]
Message-ID: <20240619175633.M826655@dcvr> (raw)
In-Reply-To: <xmqqzfrhyg8j.fsf@gitster.g>
Junio C Hamano <gitster@pobox.com> wrote:
> Eric Wong <e@80x24.org> writes:
>
> >> Yes, using Perl is a good substitute for writing it in C in this
> >> case. I however question the choice to use t9700/test.pl here,
> >> which is clearly stated that its purpose is to "test perl interface
> >> which is Git.pm", and added tests are not testing anything in Git.pm
> >> at all.
> >>
> >> Using t9700/test.pl only because it happens to use "perl -MTest::More"
> >> sounds a bit eh, suboptimal.
> >
> > *shrug* I figure Test::More is common enough since it's part of
> > the Perl standard library; but I consider Perl a better scripting
> > language than sh by far and wish our whole test suite were Perl :>
>
> Oh, I think we (actually the author of t9700) considers it common
> enough that we have PERL_TEST_MORE prerequisite to allow us to write
> tests, assuming that it is available, and let us easily skip where
> it is not available. So I do not think I mind the dependency on
> Test::More at all. Moving the tests to t1006 and rewriting the
> tests not to use Test::More are two separate and unrelated things,
> and if you are more comfortable with Test::More (and more
> importantly if it is natural to write Perl based tests using
> Test::More), it is not necessary to switch away from it.
OK, fair enough. Given t1006 is mostly sh, I prefer keeping v2
as-is because the Test::More->builder munging of test numbers in
t9700/test.pl is nasty too and I wouldn't enjoy duplicating
those bits in a hypothetical t1006/test.pl, either.
It would be nice to have first class support for Test::More in
our suite so we could just have t/t0006-cat-file.t and
t/t9700-perl-git.t implemented in Perl without sh at all, but
that's a separate discussion.
next prev parent reply other threads:[~2024-06-19 17:56 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-17 10:43 [PATCH 0/2] cat-file related doc and test Eric Wong
2024-06-17 10:43 ` [PATCH 1/2] Git.pm: use array in command_bidi_pipe example Eric Wong
2024-06-17 20:33 ` Junio C Hamano
2024-06-17 10:43 ` [PATCH 2/2] t9700: ensure cat-file info isn't buffered by default Eric Wong
2024-06-17 20:50 ` Junio C Hamano
2024-06-18 21:30 ` [PATCH v2 2/2] t1006: " Eric Wong
2024-06-18 23:37 ` Junio C Hamano
2024-06-19 17:56 ` Eric Wong [this message]
2024-06-20 17:28 ` Junio C Hamano
2024-06-21 7:16 ` Jeff King
2024-06-21 20:00 ` Eric Wong
2024-06-24 15:19 ` Jeff King
2024-06-17 23:08 ` [PATCH 2/2] t9700: " Junio C Hamano
2024-06-19 9:08 ` Phillip Wood
2024-06-19 18:08 ` Eric Wong
2024-06-21 13:03 ` Phillip Wood
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=20240619175633.M826655@dcvr \
--to=e@80x24.org \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.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.