From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: Taylor Blau <me@ttaylorr.com>, Christian Hesse <list@eworm.de>,
git@vger.kernel.org, Christian Hesse <mail@eworm.de>
Subject: Re: [PATCH 1/1] imap-send: include strbuf.h
Date: Thu, 18 May 2023 14:25:04 -0400 [thread overview]
Message-ID: <20230518182504.GA557383@coredump.intra.peff.net> (raw)
In-Reply-To: <xmqq7ct5vdbk.fsf@gitster.g>
On Thu, May 18, 2023 at 09:01:19AM -0700, Junio C Hamano wrote:
> Taylor Blau <me@ttaylorr.com> writes:
>
> >> My inclination is punt and simply do not to claim that we have done
> >> a good due diligence to ensure with all permutations of ifdef we are
> >> including necessary headers.
> >
> > I think that's the best course of action, too. I see that it's already
> > on 'next', thanks.
>
> Yeah, I am actuall hoping that somebody clever, with time, comes up
> with a systematic way to give us better coverage, but until then, I
> think it is better to honestly record where we are to future
> developers.
I faced a similar issue with the -Wunused-parameter patches. Just when I
thought I had everything annotated, I'd find some obscure Makefile knob
that compiled new code (or even in one case disabled some code that used
a variable!).
I never came up with a good solution, but relying on CI helped, since it
just builds more of the combinations. Obviously that didn't catch this
case. We could try to hit more platforms / combinations of knobs in CI,
but there are diminishing returns on the compute time.
But at least in this case, the old "if it is important, somebody will
build it and report the problem" line of thinking worked out. So maybe
that is enough.
I guess maybe that was more philosophical than helpful. ;)
-Peff
next prev parent reply other threads:[~2023-05-18 18:25 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-17 7:06 [PATCH 1/1] imap-send: include strbuf.h Christian Hesse
2023-05-17 15:49 ` Junio C Hamano
2023-05-17 16:02 ` Taylor Blau
2023-05-17 16:19 ` Junio C Hamano
2023-05-17 16:31 ` Taylor Blau
2023-05-17 20:12 ` Christian Hesse
2023-05-17 20:18 ` Christian Hesse
2023-05-18 15:56 ` Junio C Hamano
2023-05-17 16:23 ` Taylor Blau
2023-05-17 16:53 ` Junio C Hamano
2023-05-17 17:01 ` Junio C Hamano
2023-05-17 17:58 ` Taylor Blau
2023-05-17 18:06 ` rsbecker
2023-05-17 18:12 ` Junio C Hamano
2023-05-17 19:30 ` rsbecker
2023-05-17 18:09 ` Junio C Hamano
2023-05-17 21:38 ` Taylor Blau
2023-05-18 16:01 ` Junio C Hamano
2023-05-18 18:25 ` Jeff King [this message]
2023-05-18 20:49 ` Junio C Hamano
-- strict thread matches above, loose matches on Subject: below --
2024-02-09 22:26 Christian Hesse
2024-02-09 22:42 ` Junio C Hamano
2024-02-09 22:54 ` Junio C Hamano
2024-02-10 20:01 ` Christian Hesse
2024-02-11 2:42 ` 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=20230518182504.GA557383@coredump.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=list@eworm.de \
--cc=mail@eworm.de \
--cc=me@ttaylorr.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 read-only IMAP folder(s) and NNTP newsgroup(s).