I disagree. If you look back and all you see are commit messages summarizing the diff, you won't get any meaningful information.
Telling me `Changed timeout from 30s to 60s` means nothing, while `Increase timeout for slow <api name> requests` gives me an actual idea of why that was done.
Even better if you add meaningful messages to the commit body.
Take a look at commits from large repositories like the Linux kernel and we can see how good commit messages looks like.
> Interesting idea. But those say what’s in the commit. The commit diff already tells you that. The best commit messages IMO tell you why you did it and what value was delivered.
Which doesn't include what was done. Your example includes both which is fine. But not including what the commit does in the message is an antipattern imho. Everything else that is added is a bonus.
Many changes require multiple smaller changes, so this is not always possible.
For me the commit message should tell me the what/why and the diff is the how. It's great to understand if, for example, a change was intentional or a bug.
Many times when searching for the source of a bug I could not tell if the line changed was intentional or a mistake because the commit message was simply repeating what was on the diff. If you say your intention was to add something and the diff shows a subtraction, you can easily tell it was a mistake. Contrived example but I think it demonstrates my point.
This only really works if commits are meaningful though. Most people are careless and half their commits are 'fix this', 'fix again', 'wip', etc. At that point the only place that can contain useful information on the intentions are the pull requests/issues around it.
I don't know when do you think I wrote that "the how" was needed because of course it's not needed. Again, OP wrote about just having "the why" in the message which is bad imho and you need "the what" there as well. As per your commit, the title is "fix crash when enabling pass-through port" which is exactly what I mean - it says what was done in a clear manner.
Telling me `Changed timeout from 30s to 60s` means nothing, while `Increase timeout for slow <api name> requests` gives me an actual idea of why that was done.
Even better if you add meaningful messages to the commit body.
Take a look at commits from large repositories like the Linux kernel and we can see how good commit messages looks like.