From: Jeremy M. Dolan <[email protected]>
> 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
Wayne Scott wrote:
> From: Jeremy M. Dolan <[email protected]>
>
>>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.
Which is why 2.5.1 is the only time it can go in.
It would save 140K compressed (bz2) which kernel.org
would probably appreciate, but it's probably too late
already so the next best is always do it for subsequent patches.
Perhaps their should be a patch_pp script that does runs
both Lindent and strip_ws? Actually Alan Cox mentioned to
me that pine had a bug where it stripped whitespace at end
of lines :-) can't depend on that though.
Padraig.
* Wayne Scott <[email protected]> on Thu, Nov 29, 2001:
> From: Jeremy M. Dolan <[email protected]>
> > 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.
>
diff -w, diff -b, diff -B
M. R.