lkml.org 
[lkml]   [2001]   [Nov]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: Extraneous whitespace removal?
From
From: Jeremy M. Dolan <jmd@turbogeek.org>
> Pluses:
> - clean up messy whitespace
> - cut precious picoseconds off compile time
> - cut kernel tree by 200k (+/- alot)
>
> Minuses:
> - adds 3.8M bzip2 or 4.7M gzip to next diff

As someone who has spend a lot of time working on version control and
file merging, let be tell you the big minus you missed.

After this patch go into the Linux kernel, everyone who is maintaining
a set of patches in parallel with the main kernel has a lot of extra
work resolving the conflicts caused by this change. You have touched
a huge number of lines and people will have to walk a list of merge
conflicts everywhere they have made local changes and pick their side.
And anytime people do a whole series of the same edits over and over
they will miss that real conflict in the middle and lose some
important change.

The other problem that occurs is for people who maintain version
histories. It is really useful to know where (and why) a line was
last changed. This obscures that information by a layer of edits that
made no change.

While saving a little space is nice, it is not worth the pain and risk
it involves. I much prefer the solution suggested where incoming
patches are filtered before they are applied. Used consistantly, the
whitespace will be removed over time.

-Wayne
-
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: 2005-03-22 13:13    [W:0.048 / U:1.816 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site