From: Junio C Hamano <gitster@pobox.com>
To: Christian Hesse <list@eworm.de>
Cc: Philippe Blain <levraiphilippeblain@gmail.com>,
Git Mailing List <git@vger.kernel.org>,
Christian Hesse <mail@eworm.de>
Subject: Re: [PATCH 1/1] imap-send: include strbuf.h
Date: Sat, 10 Feb 2024 18:42:28 -0800 [thread overview]
Message-ID: <xmqq7cjbbu23.fsf@gitster.g> (raw)
In-Reply-To: <20240210210155.71fa163d@leda.eworm.net> (Christian Hesse's message of "Sat, 10 Feb 2024 21:01:55 +0100")
Christian Hesse <list@eworm.de> writes:
>> Oops, missing link:
>>
>> https://lore.kernel.org/git/pull.1664.git.git.1706833113569.gitgitgadget@gmail.com/
>
> Sorry, missed that... Probably because the breakage went into 2.43.1, but the
> upstream fix did not. So sorry for the noise.
Please don't be. Duplicated reports are much much better than no
reports due to "well, this must have been reported already by
somebody else". Thanks for reporting.
> Anyway... does it make sense to move the include into the condition?
I do not think so. The original breakage was because it implicitly
relied on the fact that http.h, which is included only when
USE_CURL_FOR_IMAP_SEND is defined, happens to include strbuf.h, even
though the code that does not rely on USE_CURL_FOR_IMAP_SEND do
unconditionally rely on the strbuf facility being available to them,
possibly combined with the fact that not too many people build
imap-send with USE_CURL_FOR_IMAP_SEND disabled.
So the conditional thing still rely on an implicit assumption you
are making, i.e. "http.h will forever be including strbuf.h", which
is fragile when people from time to time come and make sweeping
"header clean-up". Which is a good thing. But we need to be
careful, and one way to help us being careful against such a header
clean-up is to make sure you include what you use yourself, instead
of assuming that somebody else you include will keep doing so.
next prev parent reply other threads:[~2024-02-11 2:42 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-09 22:26 [PATCH 1/1] imap-send: include strbuf.h 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 [this message]
-- strict thread matches above, loose matches on Subject: below --
2023-05-17 7:06 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
2023-05-18 20:49 ` 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=xmqq7cjbbu23.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=levraiphilippeblain@gmail.com \
--cc=list@eworm.de \
--cc=mail@eworm.de \
/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).