[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wimQi=gL-Pd7kMd-ruwjLUCK82e3wJ7sisvT3cfHrx-JQ@mail.gmail.com>
Date: Tue, 21 Feb 2023 15:15:09 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Heiko Carstens <hca@...ux.ibm.com>
Cc: Vasily Gorbik <gor@...ux.ibm.com>,
Alexander Gordeev <agordeev@...ux.ibm.com>,
Christian Borntraeger <borntraeger@...ux.ibm.com>,
Gerald Schaefer <gerald.schaefer@...ux.ibm.com>,
linux-s390@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL] s390 updates for 6.3 merge window
On Mon, Feb 20, 2023 at 4:02 AM Heiko Carstens <hca@...ux.ibm.com> wrote:
>
> Also the shortstat when merging will look slightly different to the one
> generated with 'git request-pull' below, since I merged our fixes branch
> twice to avoid merge conflicts.
Please don't do that unless the merge conflicts are really nasty - and
when you do, please *explain* it.
Looking at those two merges, I
(a) see no sign of complex conflicts (the conflict diff is completely
empty for both of them)
(b) see zero explanation for why the merge exists at all
Please consider merges to be real commits (they are!) and needing all
the same commit messages explaining them that normal commits have
(they do!).
In fact, exactly because merges don't have any obvious code in them,
they probably need *more* of an explanation than a commit where the
diff might be in itself somewhat self-documenting.
Linus
Powered by blists - more mailing lists