3 ms·

It's true that giving a little potted history like this is "good" (other than he should have made a nice informative first line for summaries) BUT it's not sup

It's true that giving a little potted history like this is "good" (other than he should have made a nice informative first line for summaries) 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 have many instances where I could do a longer story like this but it would be exhausting to do it every time. I try to do it when the commit might look unclear in intent or effect to an outsider, when the change is being made for an important reason, /and/ where this a potentially negative consequence (like naively reverting or writing bad code) if the change is not explained. I think this is a decent example of that but not great, because no one is intentionally going to go in and start introducing nonbreaking spaces.

cesarb 3y ago
> 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.