Re: merging pull requests

[Linus Torvalds <torvalds@linuxfoundation.org>]

On Fri, Oct 1, 2021 at 11:26 AM Konstantin Ryabitsev
<konstantin@linuxfoundation.org> wrote:
>
> I think Linus just manually adds "(patches from Andrew)" to that.

I always manually edit my merge messages fairly extensively.

And I would very much discourage anybody from thinking that a merge
commit could be auto-generated. Don't do it. If you do it, you're
doing things wrong.

Merge messages need to be meaningful, and no amount of auto-generation
will ever make them so.

Even when people use signed tags with all the merge message in them to
send me pull requests, I will edit things so that at a minimum there's
proper indentation for me quoting the data, but also to try to make
merges look somewhat consistent (different people use very different
formats for listing changes).

I'll spend time making my merge messages look more legible, including
fixing spelling and grammar for people, and sometimes going to look at
the individual commits themselves if there is some explanation that
doesn't make sense to me.

Yeah, some trivial pull requests with a couple of simple changes,
maybe the auto-generated shortlog feature ends up being sufficient.
but honestly, that's _very_ rare. And sometimes the message might be
just "Small x86 fixes" like in the recent kvm pull I did.

But if the pull has anything even remotely more subtle, I will
complain to whoever sent me the pull request if they didn't give me
enough information.

And honestly, when _I_ merge stuff, I generally will need to explain
things _less_ than most other people, for one very simple and
fundamental reason: my tree is simply the known upstream tree. So me
merging some networking pull should explain _what_ I merge, but at the
same time, I don't really need to explain why it is _I_ that am
merging it.

When you see me merging networking code into my tree, a simple "Merge
networking fixes from David/Jakub" is already enough information.
There's no question about "why is Linus merging from the networking
maintainers".

So then I get very upset when I see other people merge stuff, and they
have NO explanations at all.

If you aren't the upstream maintainer for whatever you are merging,
you should not only explain *what* you are merging, you should explain
*why* you are merging it.

So put simply: I put a fair amount of effort into making my merge
messages be meaningful.

Anybody else who does merges should do at LEAST the same, and in
situations where you're merging something that you aren't the obvious
maintainer for (like doing back-merges of my tree), you should in fact
put a lot *more* effort into it.

End result: Please don't make some crazy "b4 shazam" tool that handles
pull requests and then makes it trivial for people to do automated
merges too. That's absolutely the last thing we want to see.

Merges need *more* explanation than regular commits. The "why" is
often very important for a merge, even if you'll sendom see it in my
merges where the "why" is kind of implicit.

Don't try to do something that avoids that very important manual
editing step to explain what is going on.

I've said it many times before, and I'll sadly probably have to say it
many times again: if you can't be bothered to write a good merge
message, you shouldn't be doing the merge.

It really is that simple.

No automated merges outside of pure test-trees (ie where the merges
will never be seen by anybody else), because they fundamentally
violate that very basic rule.

             Linus