[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wgQBgkut6zXTbZN45AtJmSceXwDw6Y60ZmwrPkOL__A8g@mail.gmail.com>
Date: Tue, 7 Sep 2021 12:36:25 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Bartosz Golaszewski <brgl@...ev.pl>
Cc: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
Linus Walleij <linus.walleij@...aro.org>,
"open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] gpio: updates for v5.15
On Tue, Sep 7, 2021 at 1:36 AM Bartosz Golaszewski <brgl@...ev.pl> wrote:
>
> We also have a new/old GPIO driver for rockchip - this
> one has been split out of the pinctrl driver, hence the pull from the
> pinctrl tree you can see in my branch. Another merge in the tree is from Andy
> for the intel drivers.
I appreciate the heads-up, but just *look* at those merges.
The intel GPIO merge at least talks about what it does, and looks
sane. I'm not convinced that automated shortlogs are great, but
whatever. The merge isn't bad.
The rockchip one?
All I can say is "WTF?"
This is the complete and full commit message:
Merge branch 'ib-rockchip' of
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl
into gpio/for-next
what part of that screams "that's an acceptable commit message" to you?
If the reason for that merge was that you want to have the current
state so that you can split it up, then SAY SO, for chrissake!
Not that useless commit message.
Why do I have to tell this to people SEVERAL TIMES EVERY SINGLE MERGE WINDOW?
Merge commits need explanations. They need explanations for why the
merge is done, and what the merge pulls in. Not this "single line that
doesn't explain anything".
Dammit.
I've pulled this, but I'm upset. I'm upset because I've told people
literally hundreds of times by now. Merge commits are not some trivial
thing that should be ignored. Quite the reverse. Merge commits are
generally worth *more* explanation than normal commits, and should
take *more* effort and thought than some random code commit that is
obvious from just the code.
Exactly because merges are *not* obvious from just looking at the
code. It's not some one-liner that is self-explanatory.
If you cannot be bothered to make proper merge messages, then don't do
the merge. If y ou don't have a good reason for the merge that you can
articulate, then don't do the merge. If you can't explain what you are
merging, then don't do the merge.
It really is that simple.
I've pulled this, but I'm really fed up.
Linus
Powered by blists - more mailing lists