> BUT it's not super useful to say this is good, the hard part is knowing WHEN to put this much effort in and when you can skip it. I learned git in the contex

> BUT it's not super useful to say this is good, the hard part is knowing WHEN to put this much effort in and when you can skip it. I learned git in the context of Linux kernel development (its original use case). In that context, the commit message is where you explain, to whoever is reading, what your change does and why it should be accepted. The more subtle the change is, the longer and more detailed the explanation must be to convince a reviewer. So basically, the rule of thumb would be: pretend you're going to email your commit to another developer, who has the power to accept or reject your change, and who is not going to consider anything outside that email in their decision. The more subtle your change is, the more detailed and convincing its explanation has to be.