[GIT PULL] mtd: Changes for 6.17

[Linus Torvalds]

On Mon, 4 Aug 2025 at 07:40, Pratyush Yadav <pratyush at kernel.org> wrote:
>
> >
> > I'm fine either ways, but I assumed until now that the preferred form
> > was plain text descriptions.
>
> Okay, fair enough. I can do plain text next time around.

I'm actually fine either way - what I care about is that it's a
human-readable explanation of what is going on, and what I get when I
pull.

It should also strive to not only be relevant to me when I pull, but
also hopefully be relevant to others if they end up having to look at
the resulting merge - perhaps due to bugs that got introduced.

So in a perfect world, think about how to explain to me what I'm
getting in the pull, but also explaining to somebody who is in the
middle of a bisect, and notices that the problem they are trying to
figure out was introduced by merging that tree/

Or maybe the bisect is down to two or three merges, and the person
bisecting - who does *NOT* necessarily know anything about those
subsystems - is trying to judge what is the most likely culprit to
speed up bisection. A good merge message - from the pull request -
gives outsiders a feel for what hs going on and whether that merge is
likely to be relevant to them.

(And yes, I often find myself to be that person: I bisect some issue
pretty much every single merge window, and while I usually have a good
idea of what is going on, and just trust "git bisect" to do the right
thing, I *do* end up looking back at merges to see where I am in the
bisection process)

It can be bullet points when that makes sense, or it can be more of a
plain text explanation of the background to a change.

What I don't want is some cryptic "this is just the shortlog". I can
see that in git. The difference between a shortlog and a commit
message is that the commit message should *explain* what is going on.

Sometimes the two can be the same. Sometimes things are just so
obvious that they don't need further explanation than a one-liner. If
a commit fixes a NULL pointer dereference due to a missing check, it's
not like you need to say more than that.

Also note that sometimes the explanation can be *shorter* than the
shortlog. If there are a hundred small independent details that got
fixed, listing them one by one doesn't make it human-readable.

So being human-readable can mean expanding on *why* something
happened. But it can also be about giving a top-level view of lots of
individually irrelevant details.

             Linus