Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Tue, 2 Nov 2021 18:16:49 +0000
From:   Wei Liu <wei.liu@kernel.org>
To:     Linus Torvalds <torvalds@linux-foundation.org>
Cc:     Wei Liu <wei.liu@kernel.org>,
        Linux on Hyper-V List <linux-hyperv@vger.kernel.org>,
        Linux Kernel List <linux-kernel@vger.kernel.org>,
        kys@microsoft.com, haiyangz@microsoft.com, decui@microsoft.com,
        Stephen Hemminger <sthemmin@microsoft.com>,
        Michael Kelley <mikelley@microsoft.com>
Subject: Re: [GIT PULL] Hyper-V commits for 5.16
Message-ID: <20211102181649.pc3nhrajmyhd4fnq@liuwe-devbox-debian-v2>
References: <20211102131309.3hknsf66swvkv6hm@liuwe-devbox-debian-v2>
 <CAHk-=wges7MttbFTQ9=YykWmn=B4F5pQsZNKNuxmyA1CUM7hNQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAHk-=wges7MttbFTQ9=YykWmn=B4F5pQsZNKNuxmyA1CUM7hNQ@mail.gmail.com>
Precedence: bulk

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@kernel.org> 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