Hard disagree, though it’s probably dependent on your domain and/or how expressive your test suite is.

But even if that were true, reading a two liner explanation is very obviously more time efficient than reviewing a whole commit diff.

Super common case: you got a subtle bug causing unexpected values in data. You know from the db or logs that it started on 2025-03-02. You check the deployment(s)of that day and there are ~20 of them.

You can quickly read 20 lines in the log and have a good guess of which is likely to be related or go for a round of re-reviewing 20 multi file pull requests and reverse engineer the context from code.

"Super common case" is "initial commit", "fix spelling in README.md", or "small refactor". If your "super common case" is "subtle bug causing unexpected values in data" then you are doing something very, very wrong.

Man, 99% of non-bug-fix commits don't have a why other than "advance the current task".

Almost all commits live in tandem with some large feature or change being made. The reason for absolutely all of them is the same - build the thing .

>other than "advance the current task"

How do you expect someone to know what “the current task” was when they’re tracking down a bug 2 years down the line?

Then write that and link to the current task. That's the why. You don't need an LLM for that.

Perhaps this is about commit granularity. If keeping the history about advancing the task is not useful, then I’d merge these commits together before merging the PR; in some workflows this is set up to happen automatically too.

Maybe what we need is a pre-commit hook that prefixes every commit with the name of the branch it's being made onto