linux-kernel - Re: [GIT PULL] libnvdimm for 4.18

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sat, 9 Jun 2018 08:17:27 -0700
From:   Dan Williams <dan.j.williams@...el.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "linux-nvdimm@...ts.01.org" <linux-nvdimm@...ts.01.org>,
        Linux ACPI <linux-acpi@...r.kernel.org>
Subject: Re: [GIT PULL] libnvdimm for 4.18

On Fri, Jun 8, 2018 at 5:26 PM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
> On Fri, Jun 8, 2018 at 5:19 PM Linus Torvalds
> <torvalds@...ux-foundation.org> wrote:
>>
>> If I get stuff that looks at all complex at the end of the merge
>> window, I will just cackle unpleasantly while I press the big 'D' key
>> on my keyboard.
>
> Side note: looking at what I just pulled, there was close to a D key here too.
>
> Dammit, the top commit in your tree is a merge. And the merge message
> for that merge is this:
>
>     Merge branch 'for-4.18/mcsafe' into libnvdimm-for-next
>
> That's it. One line. That doesn't say anything at all.
>
> That kind of uninformative commit message wouldn't be remotely
> acceptable for a regular simple one-liner patch.
>
> WHY THE HELL DO PEOPLE CONTINUE TO THINK THAT IT'S OK FOR MERGES?
>
> Dammit. Merges are *more* complex than random usual patches. They need
> proper commit messages. Yet you have two merges there with absolutely
> *no* information in the commit message.
>
> If you can't be bothered to write an informative commit message for a
> merge, you damn well shouldn't do the merge.
>
> It really is that simple.

Well, crap. I've been doing it the wrong way for a while. Do you have
a preference for more pull requests or just splitting what is now a
top level tag message into a summary changelog per branch when I merge
the ready branches for the merge window? I had been assuming that the
arrangement you have with Ingo / Thomas to pull individual topics was
a privilege for the tip tree and not necessarily something everyone
that sends you pulls should be doing.