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.

>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