<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Jun 23, 2014 at 4:43 AM, Jay Pipes <span dir="ltr"><<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On 06/22/2014 09:41 AM, Amrith Kumar wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In addition to making changes to the hacking rules, why don't we mandate also<br>
that perceived problems in the commit message shall not be an acceptable<br>
reason to -1 a change.<br>
<br>
Would this improve the situation?<br>
</blockquote>
<br></div>
I actually *do* think a very poor commit message for a substantial patch deserves a -1. The git commit message is our history for the patch, and it is important in its own right. Now, nits like a single misspelled word or the commit summary being 60 characters instead of 50 are not what I'm talking about, of course.<br>

<br>
I'm speaking only about when a commit message blatantly disregards the best practices of commit message writing [1] and doesn't offer anything of value to the reviewer.<br>
<br></blockquote><div><br></div><div>+1. <br><br>Minor typos and grammatical errors I don't  care about (but will put in suggested fixes if the patch needs to be updated anyway). However, commit messages are very important for future debugging. One or two line vague commit messages can make life a lot harder for others in the future when writing a short description is not what I'd consider an excessive burden. And there should be no assumption that the person reading the commit message will have easy access to the bug database.<br>
<br></div><div>Chris<br><br></div></div></div></div>