From: Jeff King <firstname.lastname@example.org>
To: Taylor Blau <email@example.com>
Cc: Thomas Braun <firstname.lastname@example.org>,
Derrick Stolee <email@example.com>,
Subject: Re: [PATCH 0/5] handling 4GB .idx files
Date: Wed, 2 Dec 2020 08:12:53 -0500 [thread overview]
Message-ID: <X8eS1Zrqk99AjKkD@coredump.intra.peff.net> (raw)
On Tue, Dec 01, 2020 at 01:27:26PM -0500, Taylor Blau wrote:
> I have a sense that probably very few people actually run GIT_TEST_LONG
> regularly, and that that group may vanish entirely if we added a test
> which increased the runtime of the suite by 20x in this mode.
Yeah, and if that's so, then I'm OK with calling it EXPENSIVE and moving
on with our lives. And I guess merging this is one way to find out, if
anybody screams. The stakes are low enough that I don't mind doing that.
> I have mixed feelings about VERY_EXPENSIVE. On one hand, having this
> test checked in so that we can quickly refer back to it in the case of a
> regression is useful. On the other hand, what is it worth to have this
> in-tree if nobody ever runs it? I'm speculating about whether or not
> people would run this, of course.
> My hunch is that anybody who is interested enough to fix regressions in
> this area would be able to refer back to the list archive to dig up this
> thread and recover the script.
> I don't feel strongly, really, but just noting some light objections to
> checking this test into the suite.
Yeah, that about matches my feelings. But if Thomas wants to wrap it up
as a patch, I don't mind seeing what happens (and I think with the
suggestions I gave earlier, it would be in good shape).
prev parent reply other threads:[~2020-12-02 13:14 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-13 5:06 [PATCH 0/5] handling 4GB .idx files Jeff King
2020-11-13 5:06 ` [PATCH 1/5] compute pack .idx byte offsets using size_t Jeff King
2020-11-13 5:07 ` [PATCH 2/5] use size_t to store pack .idx byte offsets Jeff King
2020-11-13 5:07 ` [PATCH 3/5] fsck: correctly compute checksums on idx files larger than 4GB Jeff King
2020-11-13 5:07 ` [PATCH 4/5] block-sha1: take a size_t length parameter Jeff King
2020-11-13 5:07 ` [PATCH 5/5] packfile: detect overflow in .idx file size checks Jeff King
2020-11-13 11:02 ` Johannes Schindelin
2020-11-15 14:43 ` [PATCH 0/5] handling 4GB .idx files Thomas Braun
2020-11-16 4:10 ` Jeff King
2020-11-16 13:30 ` Derrick Stolee
2020-11-16 23:49 ` Jeff King
2020-11-30 22:57 ` Thomas Braun
2020-12-01 11:23 ` Jeff King
2020-12-01 11:39 ` t7900's new expensive test Jeff King
2020-12-01 20:55 ` Derrick Stolee
2020-12-02 2:47 ` [PATCH] t7900: speed up " Jeff King
2020-12-03 15:23 ` Derrick Stolee
2020-12-01 18:27 ` [PATCH 0/5] handling 4GB .idx files Taylor Blau
2020-12-02 13:12 ` Jeff King [this message]
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:
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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.
Code repositories for project(s) associated with this public inbox
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 read-only IMAP folder(s) and NNTP newsgroup(s).