[sbov]

I'm a fan of whys. Even for yourself. I have code I have to maintain that I wrote 10 years ago.

But it can make for long commit messages. Why also includes what alternatives you considered, and why you didn't use those.

I also like to have a digital "worksheet" for each change I do, where all my thoughts and research goes. So if all else fails, I can reference that. But no-one else can, so I like to transfer as much knowledge as possible to the commit message. At the same time, some of these go on for 5 or more pages. They also tend to be very messy. I'm not sure if it's all appropriate for a commit message.

[nine_k]

In my case, only key whats and whys go to the commit message. Most of the discussion is left in the issue tracker.

(Of course, the commit message refers to issue ID, and vice versa.)

[sanderjd]

Is there any scenario under which a long commit message is detrimental, even if "messy"?

[omouse]

It's an issue when dealing with management or clients. They can see long commits as a problem with someone with too much time on their hands.

The whole point of a version control system is that it contains everything related to the code. On lots of web dev and game projects you also commit the finalized assets (the generated javascript from coffeescript, the compressed 3d textures, etc. etc.)

[eterm]

That's not bad commit messages, that's bad client management.