[bonestamp2]

> I am forever grateful to past engineers for outlining WHY they made their changes, and not WHAT the changes were per se.

So true, we have this one senior developer who gets mad if someone's algorithm isn't as efficient as it could be (fair enough I suppose). But we can't get him to use commit messages that are more than 1-3 words and simply mention a word or three about the area of code that was changed. Years later, he also can't remember WHY he made those changes, so I'd much rather work with someone who writes inefficient algorithms that are easily improved at any time than commit comments that are forever useless.

What was changed is easily seen in the commit itself, why needs to be in the commit message.

[_diligenteng]

I wonder why is it so hard for people to right good commit messages. At my company I've actually tried trying talking in-person to people, even write a doc explaining the benefits and how to do it, pointing people to good resources like this one: https://chris.beams.io/posts/git-commit/

And still, I can't get people to do it. I find it so valuable to look at commit messages that are written, that explains the why behind the changes in the commit but can't get people to see the same value as I do. Any tips on that? Would be really appreciated. :)

[mandeepj]

"What was changed is easily seen in the commit itself, why needs to be in the commit message."

Commit message is like subject of an email. Is n't it faster to look at commit message, and get an idea about change rather than go through commit and understand it?

[JohnFen]

The first line of the commit message should be the "subject line". The rest of the commit message should contain a summary of the high-level stuff such as the "why".

[bonestamp2]

Yes, fair enough... having both in the commit message is ideal. I just mean that the absolute minimum is the why because at least the what can be deconstructed from the commit.