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

[Wei Liu]

On Tue, Nov 02, 2021 at 11:11:29AM -0700, Linus Torvalds wrote:
> 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.
> 

Okay. Noted. Thanks for pulling in those patches. I will keep what you
said above in mind for future PRs.

Wei.

>                Linus