Re: [PATCH v5 4/9] status: collect per-file data for --porcelain=v2

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 8, 2016, 01:57 UTC
Message-ID: <xmqqy448ggyv.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <20160807222903.GA462@starla>

Eric Wong <e@80x24.org> writes:

Show 19 quoted lines

>> > Not a big deal (no need to resend for this one alone), but let's
>> > make the above properly formatted, i.e.
>> > 
>> > 		if (ce_stage(ce)) {
>> >                 	...
>> > 		} else {
>> >                 	...
>> > 		}                        
>> 
>> Do I understand correctly that your objections is against having the curly
>> brace before the "else" on its own line?
>> 
>> If so, when did our coding style change? I vividly remember that we
>> strongly favored putting the "else" on a new line after a closing brace,
>> to make diffs nicer in case the braces were removed or added.
>
> AFAIK, Linux kernel CodingStyle has always been what Junio
> suggested (just w/o the trailing spaces :),
> and we inherit from that.

What Eric said.

While I admit that I sometimes break line between "}" and "else {" by inertia when I am being careless and get caught by checkpatch.pl myself, I do not recall trying to justify it; you probably may remember somebody else saying that, but I don't recall anybody making that argument on the list, and more importantly I don't recall us making that our style based on that argument.

The only two and half kinds of warnings we knowingly ignore from scripts/checkpatch.pl in the Linux kernel source tree are:

 * "Avoid typedefs."  We do avoid making graduitous use of typedef to
   hide a structure behind a type and pretty much limit ourselves to
   use it for (callback) function types, though.

 * "We've never heard of Helped-by/Mentored-by footers"; well,
   kernel folks may not, but we have ;-)

 * "No spaces for bitfield width".  This may not be justifyable, but
   the majority of our bitfield widths are defined in the way not
   blessed by checkpatch.pl checker.