Messages in this thread | | | Date | Thu, 29 Nov 2001 09:40:40 -0500 (EST) | Subject | Re: Extraneous whitespace removal? | From | Wayne Scott <> |
| |
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/
| |