[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wgw++ccN-Pd1npZsBSDD3z6EGUSKsWuAEh5YC-TmfJAug@mail.gmail.com>
Date: Tue, 21 Feb 2023 11:16:33 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Kees Cook <keescook@...omium.org>
Cc: linux-kernel@...r.kernel.org,
Paulo Miguel Almeida <paulo.miguel.almeida.rodenas@...il.com>,
Sam James <sam@...too.org>,
Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
Eric Biggers <ebiggers@...nel.org>,
Stephen Rothwell <sfr@...b.auug.org.au>,
linux-hardening@...r.kernel.org
Subject: Re: [GIT PULL] hardening updates for v6.3-rc1
On Fri, Feb 17, 2023 at 11:38 AM Kees Cook <keescook@...omium.org> wrote:
>
> Please pull these hardening updates for v6.3-rc1.
So I've pulled this, but while looking at it, I see commit
5c0f220e1b2d ("Merge branch 'for-linus/hardening' into
for-next/hardening").
And that one-liner shortlog part is literally the whole commit message.
I've said this before, and apparently I need to say this again: if you
cannot be bothered to explain *WHY* a merge exists, then that merge is
buggy garbage by definition.
This really should be a rule that every single developer should take
to heart. I'm not just putting random words together in a random
order.
I repeat: if you cannot explain a merge, then JUST DON'T DO IT.
It's really that simple. There is absolutely *NEVER* an excuse for
merges without explaining why those merges exist.
In this case, I really think that merge should not have existed at
all, and the lack of explanation is because there *IS* no explanation
for it.
But if there was a reason for it, then just state it, dammit, and make
that merge commit look sensible.
Because right now it just looks entirely pointless. And I literally
*detest* pointless merges. They only make the history look worse and
harder to read.
Linus
Powered by blists - more mailing lists