Agreed, but in this case, it was an encoding/whitespace change so there isn't really anywhere else to put this info.
IMO the repo is the code
However, I would have done a simpler commit and linked to an issue where I explained the problem/solution in more detail
This assumes your issue tracker doesn't change. I've been at my current position 8 years, and in that time we've had 3, and the first 2 are shut down.
Comments about the code should be in the code, where the next dev will see it. The more trivial a change, with far- reaching implications, the more important this is.
Doing so has heaps of benefits: future devs understand ramifications, shows that this code has been scrutinized, makes it easier when doing refactoring /yanking, or porting code.
That said, leaving the life story out will always be a good idea.