It does affect readability! That's the reason we have punctuation rules in human languages.
Maybe it doesn't have any effect when reviewing _one_ commit message, but when you're reading a list of hundreds, or thousands of them, it does have a huge impact.
This messages are meant to be consumed by humans, as in natural language. So it should respect the rules / conventions of that natural language.
The same way when we write code we should respect the coding style of the code base we are working on, we should respect the style conventions of the natural languages. Because of the same reasons.
Also, even if it doesn't affect you, that is completely irrelevant for the project. A project should be oblivious to any one developer's preferences. Successful software projects thrive on conventions that affect the whole project. People do what's implicitly or explicitly agreed on, a person can't just ignore rules he doesn't see the value of.
People generally accept that when it's about coding conventions. Commit messages are just another convention. The rules are not arbitrary, in fact, if you read the Linux commit style guide, it will try to explain the value of the conventions.
If you still don't get it, or you disagree, too bad. Conventions are much more important that individual opinions. If you prefer spaces, you'd better start using tabs when you want to contribute to the Linux kernel.
(By you I meant, of course, some abstract person who doesn't see the value of certain rules, not kolme who I am responding to).
A project can't be completely oblivious to preferences. You'll never find something that everyone agrees on. Eventually you have to pick something that's acceptable to the majority of the people working on the project and move on.
Of course in the case of projects a developer is working on solo, they're free to do whatever they want ;) When I'm working with others, I still express my own preferences, but I'm willing to go along with whatever the group consensus is because I'd rather be consistent above anything else.
I've never seen a project use commit messages with periods and I've never felt like it affected readability at all. I don't think it really has anything to do with natural language style conventions. Writing a paragraph consisting of several sentences is very different from a disjoint set of statements which I have always seen separated by newlines anyway.
Its defensible to adopt an abbreviated style suitable for the context of oneliner commits in a long report. Nobody uses natural language when creating other textual reports like that - e.g. log messages, checkbook register, ships' log. They all have an encoded style unrelated to natural language.
