<html><head></head><body>I may not be a code contributor, but I do tend to read the code a lot to figure out how things work out to track down a bug. I find that format changes that are not related to code changes within the same commit just make the whole commit more complex and harder to read.<br>
<br>
My preference would be that formatting fixes to existing code should be a separate commit.<br><br><div class="gmail_quote">On February 16, 2017 6:45:28 AM PST, Niels de Vos &lt;ndevos@redhat.com&gt; wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre class="k9mail">On Thu, Feb 16, 2017 at 08:41:23AM -0500, Jeff Darcy wrote:<br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"> In the last few days, I've seen both of these kinds of review comments<br /> (not necessarily on my own patches or from the same reviewers).<br /> <br /> (a) &quot;Please fix the style in the entire function where you changed one line.&quot;<br /> <br /> (b) &quot;This style change should be in a separate patch.&quot;<br /> <br /> It's clearly not helpful to have patches delayed for both reasons.<br /> Which should prevail?  I think our general practice has been more<br /> toward (b) and that's also my personal preference.  In that case<br /> instances of (a) should not occur.  Or maybe people feel it should be<br /> the other way around.  Can we get a consensus here?<br /></blockquote><br />I do not like to have patches change the coding style alone. Only for<br />the lines at the beginning of the function I prefer to see (a) being<br />followed, but blocking a patch should not be the case. Still, if some of<br />the regular contributors do not follow the coding-style, I tend to get<br />annoyed with it and my give them a -1 in the hope they do repeat that in<br />the future. If it is really the only thing that bothers me, I tend to<br />send an updated patch for them (after a chat on IRC).<br /><br />Doing coding-style fixes on lines that have no other modifications tend<br />to make 'git blame' more difficult to follow. I use that a lot when<br />trying to figure out when a problem has been introduced. So in general,<br />I really do not like (b).<br /><br />Niels<br /></pre></blockquote></div><br>
-- <br>
Sent from my Android device with K-9 Mail. Please excuse my brevity.</body></html>