IMHO you should pick a right medium for some kind of messages and I dont think git commit message is the right medium in OP example. Most companies have ticketing tool to keep track of additional information like: how long did it take to solve that issue, was there any input from other people, long "marked up" message explaining what was wrong, how it was fixed and tested (markup is a lot easier to read than console log).
Using ticket number already forces you to use "the right tool" to view the message.
IMHO I would consider OP example as a bad practice and your example as a better solution.
The other side of this argument—why I’m torn—is that the git commit message isn’t necessarily written by the developer who developed the solution, but might instead be written by a project maintainer who received the solution as a patch, or is copying a fix from a downstream or sibling-fork project, as a standalone patch.
In other words: if you have a ticket tracker with this information captured in it, it makes some sense to just link to it. But if you have a mailing list with this information captured in it—in only the loosest amalgamation, where there’s no clear “thread” that contains the whole discussion, and the original developer of the patch might not even be a part of that discussion—then it seems like it’d be important for the final committer to write their own summary of the events that led to this commit, such that people can understand what went on if they weren’t following the list. And where do you put that summary? The commit message.
I would argue that maybe this is a core part of git’s design, given that it was developed specifically for the LKML style of “patches first, sent to a list, and then discussed in the context of what they solve”, rather than the GitHub style of “discussion first [on open issues] sparks PRs that attempt to solve [i.e. close] the issue.” Git assumes that you, as an “editor”, are going to be summarizing an otherwise-illegible discussion history for the benefit of the people viewing the commit; and so it provides a multi-line commit message as a place to stow that editorial summary.
This is awesome until you can't access the ticketing system, or there is context outside that system, or even better the company decides to change tools and loses the mapping to old issues (true story. joy of startups).
By all means put the ticket number in the header line, along with type of patch.
But do yourself a favor and put enough context in too. Doesn't have to be all the detail.
Using ticket number already forces you to use "the right tool" to view the message.
IMHO I would consider OP example as a bad practice and your example as a better solution.