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/
This archive was generated by hypermail 2b29 : Fri Nov 30 2001 - 21:00:34 EST