Re: [GIT PULL] Hyper-V commits for 5.16

[Linus Torvalds]

On Tue, Nov 2, 2021 at 6:13 AM Wei Liu <wei.liu@xxxxxxxxxx> wrote:
>
> There are two merges from the tip tree: one is because of Tianyu's
> patches went in via tip/x86/sev, the other is because a tree-wide
> cleanup in tip/x86/cc conflicted with Tianyu's patch.
>
> Instead of requiring you to fix up I thought I'd just do it myself.

Please don't do that.

Merging a pre-requisite and having a common branch that you merge - that's fine.

But don't hide merge conflicts from me by "pre-merging". It's not helpful.

And to make matters worse, both of those merges are BAD.

They have absolutely no explanation.

Christ.

For the millionth time:

   IF YOU CAN'T BE BOTHERED TO WRITE A PROPER COMMIT MESSAGE FOR A
MERGE, DON'T DO THE MERGE

I'm getting really tired of having to say this multiple times every
merge window (and often in between merge windows too).

Your merges are bad, and you should feel bad.

I've pulled this, but at some point I'm just going to have to decide
that "bad merges means I will not pull your garbage".

Merges need commit messages that explain what is going on, just as
much as any other commit does.

In fact, arguably they need *more* explanation, since they are subtler
and don't have the obvious patch associated with them that may clarify
what is going on.

So a merge message like

    Merge remote-tracking branch 'tip/x86/sev' into hyperv-next

is *NOT* an acceptable merge message. It needs an explanation of what
that SEV branch contained, and *WHY* those contents needed to be
merged into hyperv-next.

Again: if you can't explain the merge, or you can't be bothered, just
DON'T DO IT.

And no, the "hide conflicts from Linus" is _not_ an acceptable reason
to do merges.

I do so many merges that I can do most conflicts in my sleep, and
often do them as well or better than the submaintainers do. And I
write proper merge messages, and when a conflict happens it means I
*know* about it and am aware of how different trees ended up
interacting with each other - all of which is good.

Again - I've taken this pull request, but I'm not happy about those
merges. Even the merge that was perfectly fine to do wasn't done well.

               Linus