Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I've always just gone with

52 ~line~ [edit: character] summary

Then write a book, just being sure to wrap at 72 chars. Never really considered what an optimal commit message length was.

Maybe it's something along the lines of "if you are playing poker and you can't figure out who the easy money is, the easy money is you." I've never seen a commit message, PR description, etc and thought "well that was excessive," so maybe I'm the one...

This one stood out to me: 157 lines of rationale, discussion of alternatives, etc for 22 lines of uncontroversial changes[1]. It's much more likely to be useful in and of itself as a piece of documentation than a one-liner, "Changes to prevent strcpy" though.

[1]: https://github.com/git/git/commit/c8af66ab8ad7cd78557f0f9f5e...



While I'm perfectly fine with this commit-essay, and would probably be with any other, in this particular case I would also be perfectly fine with a terse "ban strcpy" + actually a few more comments in the source code.

Commit messages are not going to serve as a knowledge base for state of the art and best practices, and strcpy is universally recognized as problematic. Plus, about the how, while it is fine to see the dev thought a lot about it, did some testing, etc., the way he did the ban is ultra classic in the end. Also, it might have been even better to put some short explanations in comments instead of in just the commit message, in particular the usefulness of the BANNED macro to preserve some line numbers with gcc. So in this particular case I'm not really convinced that the commit message serves any strong purpose.

But it does not hurt. And it participates to a culture where useful commit messages are important. So I still (weakly) prefer it to my hypothetical "ban strcpy".


  #undef strcpy
Yikes…




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: