Git and Subversion even allowing single line “-m” commit messages was a mistake. That's a subjective preference. Maybe for some repos it's a good idea to allow

Git and Subversion even allowing single line “-m” commit messages was a mistake. That's a subjective preference. Maybe for some repos it's a good idea to allow or even require longer messages, but certainly not all. For example, after seeing many different strategies for commit messages over the years, my own preference in many cases is now to permit only one-line commit messages, with a strict character limit, which include a reference to a suitable source such as a feature or bug ID where more details may be found. With git, this can be checked using a pre-commit hook. The big advantage of this is that a `git log` or similar command with a single-line format can never then hide anything important. Assuming we're talking about an established project that does have things like a bug tracker and some sort of structured project documentation set up, I have found that any time I am tempted to write a longer commit message, there is usually a better place I could record that information, and if not then maybe it wasn't that important anyway. YMMV, of course. As I said, it's a subjective preference, and no doubt there are many different ways a team might choose to use their tools.