I, too, would rate this a substandard git comment. Dave basically vomited a bug ticket of information, which is highly contextual and irrelevant ... like the li

I, too, would rate this a substandard git comment. Dave basically vomited a bug ticket of information, which is highly contextual and irrelevant ... like the lines he was faced with, which tell us nothing in the future nor anything we could not see in the change. The error is known, from the ticket being addressed. Documenting what error a bundler throws in the application deployment, within git seems...silly, since it will likely not apply to all points in time. That's why we have separate issue tracking. There was a whitespace encoding issue AND the developer didn't really understand the issue, since they ended with "One hour of my life I won't get back.". Over my 20 years, I've seen this EXACT scenario multiple times across multiple companies. Some jr engineer gets stuck with some troublesome weird error in a corner-case that ends up being a non-standard whitespace. It's a learning opportunity and he lamented it because it was different and nobody told him "we could stop this from happening again, generate a new issue". There are salient improvements that the git commit would benefit from both comment changes and additional code: 1. Include a (new) feature ticket that is linked to this issue - to create a process that doesn't allow for this again (eg fix a linter) 2. Include the name of the bug ticket (Convert template to US-ASCII to fix error) in the commit title, that was being addressed. 3. Create a test to specifically enforce the us-ascii encoding or add necessary rules to a linter.