Sidney San Martín <s@xxxxxxxxxxxx> writes: >> After all, SCM is merely a method to help communication between >> developers, and sticking to the common denominator is a proven good way to >> make sure everybody involved in the project can use what is recorded in >> the repository. This is not limited only to the log message, but equally >> applies to filenames (e.g. don't create xt_tcpmss.c and xt_TCPMSS.c in the >> same directory if you want your project extractable on case insensitive >> filesystems) and even to the sources. >> >> You need to justify the cause a bit better. Why is such a new logic >> justified? > > You’re right, that sentence doesn't say anything. > > I agree that projects need to have standards for their commit messages, > but I also think that line wrapping should be taken care of by the > computer so that the humans can think about the content of their commit > messages. It's easier for everyone. I just typed M-q to wrap the above paragraph from you to make it readable. "Computers are good at automating" is true, and that is why real editors give an easy way to auto-wrap long prose in a paragraph while composing. But "computers are good at automating" is not a convincing justification to let the composer leave unreasonably long lines in the commit log object and force the reader side to line-wrap the mess only to fix it up. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html