1. Majority of commit messages are low quality and would benefit significantly from a good summary of what was done.
2. Margin of commit messages is often too small for documenting the rationale - this job is better left for tickets.
The commit message lives with the code. The number of times in my career that a company has migrated, changed, consolidated, or otherwise made all those links in commit messages obsolete, well I don't quite yet need two hands. But I see a lot of dead ends to context in code bases.
Keeping that metadata in tickets means that it can’t be read within ‘git blame’. It’s also all too easy for it to be lost entirely when changing ticketing systems, transferring codebases between teams or companies, etc.
Why? At that point doesn't the diff speak for itself?
As you say, we know what’s there. I need the author to tell me why it’s there, and perhaps what other alternatives were abandoned because they didn’t work.
You know, so I don’t waste a day finding out for myself why you didn’t just do ${obvious}.