On Sat, 23 Jun 2007, Andrew Morton wrote:
>
> Anyway. Please fix the many correct warnings which checkpatch.pl
> generates
Actually, please don't.
Especially for code movement, *just* do the movement. Screw any
checkpatch.pl crap - the code is better off not changing, because that way
a big patch can not only be proven to not change anything at all, but
software archeology tools can trivially find the true history of the code
over code movement.
For example, "git blame -C" already finds copies and can annotate the
history of a line of code past a pure code movement. But if you move *and*
change things at the same time, it gets a lot harder to show where the
code came from and that the movement itself caused no regressions.
So do cleanups _separately_ from movement.
(Yeah, yeah, "git blame -C -w" will generally work across whitespace
changes too, but only whitespace _within_ a line. If you do things like
split long lines etc, you immediately have a lot harder time to follow
these thigns. Not impossible, but the point is that you're not *fixing*
anything, you're just making things *worse* by doing changes and code
movement at the same time).
Quite frankly, I personally am considering removing "checkpatch.pl". That
thing is just a nazi dream. That hard-coded 80-character limit etc is just
bad taste.
Dammit, code cleanliness is not about "automated and mindless slavish
following of rules". A process that is too inflexible is a *bad* process.
I'd much rather have a few 80+ character lines than stupid and unreadable
line wrapping just because the line hit 87 characters in length.
I don't have 25 lines on a screen either.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
