lkml.org 
[lkml]   [2005]   [Jun]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [git patch] urgent e1000 fix


On Fri, 24 Jun 2005, Keith Owens wrote:

> On Fri, 24 Jun 2005 09:49:05 +0300,
> Denis Vlasenko <vda@ilport.com.ua> wrote:
> >On Friday 24 June 2005 02:33, Linus Torvalds wrote:
> >> To actually allow real fuzz or to allow real whitespace differences in the
> >> patch data itself is a _much_ bigger issue than this trivial patch
> >> corruption, and I'd prefer to avoid going there if at all possible.
> >
> >How about automatic stripping of _trailing_ whitespace on all incoming
> >patches? IIRC no file type (C, sh, Makefile, you name it) depends on
> >conservation of it, thus it's 100% safe.
>
> One (admittedly rare) case - adding a text file that contains an
> embedded patch, so you have a patch that includes a patch. This is
> sometimes done in Documentation files when an external file has to be
> changed. In embedded patch, empty lines are converted to a single
> space, which then appears as trailing whitespace. Not sure if that is
> a big enough reason not to strip whitespace.

There's a much more important reason never _ever_ to mess with whitespace
in patches: it by definition measn that the resulting whitespace now does
not match the thing at the other end, and that _will_ mean merge problems
later (ie subsequent patches will have increasingly incorrect whitespace,
and now everybody has to live with whitespace not being reliable).

So no. The only reliable way to handle whitespace is to never corrupt it.
Don't make excuses for broken email clients etc.

Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2009-11-18 23:46    [from the cache]
©2003-2011 Jasper Spaans