Re: [GIT PULL] i2c for v7.3, part 2

[Linus Torvalds]

On Mon, 24 Aug 2026 at 04:55, Andi Shyti <andi.shyti@xxxxxxxxxx> wrote:
>
> (I added this short introduction to the tag log, as I noticed
> you copied it from there in the past.)

Yes, so different people have different models - some people put
everything in the signed tag message, some people do all the
explanations in the email as they send out the pull request, and
others do a bit of both: the tag may contain a summary, and then the
pull request email contains some general commentary.

It's not a huge deal for me which approach people use, because I
typically end up reading and editing the merge message anyway. Partly
just to try to make the merge messages have some consistency (well, a
couple of different formats, there's no "one single merge message
format"), but mostly simply because that's my workflow around it as
part of reading the pull request explanations.

So it's not really even "extra work" for me - massanging that merge
commit message is in many ways the thing that is what I do as a
central part of familiarizing myself with what the high-level "what is
going on" is.

That said, putting the short intro into the signed tag has some
advantages - if it's all there in the tag, it's just one less
operation for me that I can mess up (most commonly by just forgetting
to integrate the email part of the message as I do the merge).

But it's really not a huge deal and there are no really hard rules.

Sometimes there's no summary (particularly if there are just a couple
of things and a summary isn't needed and makes no sense), and
sometimes the summary is all there is (because the details are just
not interesting in themselves,and the summary explains the big picture
sufficiently).

And quite often, I and submaintainers have different ideas of what is
the really relevant part, and I edit things to what I think is more
readable anyway.

In fact, the biggest help is keeping the messages neutral wrt tense
and operaitons. Your merge message was great in that respect, and I
didn't have to edit it for silly details like I often do for merge
messages.

THAT is actually a small (and unimportant) pet peeve of mine: text
like "This pull request does..." may make sense in an email (because
the email *is* a pull request), but I feel it makes absolutely no
sense in a merge commit message (because at that point it is no longer
a pull request, and it no longer "does", it "did").

Using present tense - particularly in some common forms ("This does X,
fixing Y") just is something I try to avoid. Using present tense may
again make sense at the point it was written, but two years later it's
just odd. This is why I much prefer imperative voice (ie "Fix XYZ"),
because it's neutral.

Another thing I don't love is pointless "Five patches to do XYZ". That
"five patches" is not relevant in the big picture. What might be
relevant is "Clean up ABC in otder to fix XYZ", but not how many
patches it took.

And as I don't want those kinds of things to typically be part of the
merge message, and I end up editing that kind of verbiage away,

Unless I get bored and lazy - and admittedlly "lazy" is both my middle
name and my default state of being.

                Linus