> I like to be able to read the commit line following the sentence: "This commit shall ...". I'd guess there's a near zero chance you do this when looking at (

> I like to be able to read the commit line following the sentence: "This commit shall ...". I'd guess there's a near zero chance you do this when looking at (scanning) a list of commits. This is a mnemonic for writing commit messages in the commonly accepted style. If you do that in order to help you understand a commit message every time you read one, that may be a personal thing. > Means nothing. Tells nothing. Is 1000 good or bad? No clue. Is it causing a bug? A performance issue? Was it 1000 before the commit or after applying it? Zero information. > Using the best practices the commit would read: > "Change default reader batch size to 500" or "Change default reader batch size to 1000" You realized you could ask the same questions about the versions you put forward, yes? Aside from the "Was it 1000 before the commit..." which, on our team, would be such a ridiculous question it wouldn't even enter the mind. As I said somewhere else, the headline for a celebrity dying does not ever read: "Some Celebrity Is Sick" > I'll pass and keep using the "best practice". Works for me :) > I look at how multi-million lines codebase like Linux or Emacs are doing it and use that as the authority. If it works well enough for these projects, it works well enough for smaller projects. Linux and Emacs have completely different circumstances than most software projects. The idea that cargo culting their practices is good for "smaller projects" is exactly why I wrote my article on best practices. By the way, I contribute to Emacs and I don't find their particular commit message format good or useful. It's particularly onerous, redundant, and does not tend to provide useful additional information (in particular the mandated change log portions -- people do often supply additional information, which can be useful). I tend to find the devel list and bug list more useful for the context of a change, which fits with our experience as well with work logs and project logs.