[theptip]

I don’t have a horse in the race, but the OP objections ring hollow to me.

- scope is important: true, but isn’t that derivable from the commit contents? An important sanity check on a diff is to look at the paths touched. (A “test” diff should not modify prod auth code.) but if you want to see this from —oneline, sure, I think feat(auth): is better than feat:

- wrong audience: I don’t agree. feat commits _should_ actually describe the product-facing changes. You _should_ curate a nice stack with your no-op refactor changes first, then your small new feature change atop. This is the most helpful thing to include in a diff comment. You should put anything technical in comments so they are not lost, “why I chose algorithm X” belongs in a comment or DECISIONS.md. These are all tedious things that only psychos bother doing in a commit history at a fast moving company, but on OSS projects I think it’s much more important to stash context in the commit messages.