I would strongly disagree with it, because it misses the opportunity for using the commit message as a sanity check. Accidents happen, sometimes I select the wrong file for the commit, or include changes I didn't intend.
Even for the most minor commits, including "improve comment formatting ; utils.pl" allows skimming that message and comparing it to the actual commit.
It also helps me be aware of what I'm doing, pointing and calling style.
To nitpick, the git commit already contains information about which files are affected; adding it explicitly to the commit message does not add value and, like comments, may be incorrect. I like the angular style guide's concept of "scope", like, what category or module of the application does it apply to.
That said, an "utils" file is often a smell in code organization.
> the git commit already contains information about which files are affected;
Contra: while this is true, it's worth considering how 'information about which files are effected' scales when examining the history of a repo. A commit message that simplifies and clarifies the intent is more useful than one that requires a future reader to read each git commit in full to understand the effect.
Even for the most minor commits, including "improve comment formatting ; utils.pl" allows skimming that message and comparing it to the actual commit.
It also helps me be aware of what I'm doing, pointing and calling style.
https://en.wikipedia.org/wiki/Pointing_and_calling