[g-b-r]

> As such, multiline commit messages (whether added on the command line or via the editor) seem doubly pointless to me

So your commit messages are always made of less than 80 characters, how can you claim that they are informative??

Personally I very rarely manage to keep them in a single line, almost always there's something to dump from my mind that will help a lot when I or someone else will have to deal with that commit a few months from now.

You don't read your messages because they really are not informative!

[seventh-chord]

I guess "not nonsensical" would be more appropriate than "informative" :)

I tend to dump information like that in "// NB (my name, current date) tralala"-style comments. Do you have git integrated in your editor so you have git-blame-style commit messages next to your code? If that is the case, I guess putting the information in the commit messages makes sense.

Maybe it just comes down to how we choose to store auxiliary information.

[masklinn]

> I tend to dump information like that in "// NB (my name, current date) tralala"-style comments. Do you have git integrated in your editor so you have git-blame-style commit messages next to your code? If that is the case, I guess putting the information in the commit messages makes sense.

No but blame is very close by and easy to access, so when I want to know why something was done that way it's not far away.

Comments keep getting out of sync, code gets inserted before or after, … and after a few years (or months on large codebases) it's just complete nonsense. I reserve them for stuff that's really super important to say right here (and todos).

[jfkebwjsbx]

No, commit messages are not meant for "auxiliary information", but for giving the reasoning behind a change.