The war on trailing whitespace
authorLinus Torvalds <torvalds@osdl.org>
Sun, 26 Feb 2006 17:29:00 +0000 (09:29 -0800)
committerJunio C Hamano <junkio@cox.net>
Tue, 28 Feb 2006 01:35:59 +0000 (17:35 -0800)
commit1187df57c2ee1119b7ef357cacb63d10581256bc
tree5f9b551fc1af3a0b20a38e0f3bc4072cf5b15d3d
parenta204756a45bd357280c156d01858138712493dfa
The war on trailing whitespace

On Sat, 25 Feb 2006, Andrew Morton wrote:
>
> I'd suggest a) git will simply refuse to apply such a patch unless given a
> special `forcing' flag, b) even when thus forced, it will still warn and c)
> with a different flag, it will strip-then-apply, without generating a
> warning.

This doesn't do the "strip-then-apply" thing, but it allows you to make
git-apply generate a warning or error on extraneous whitespace.

Use --whitespace=warn to warn, and (surprise, surprise) --whitespace=error
to make it a fatal error to have whitespace at the end.

Totally untested, of course. But it compiles, so it must be fine.

HOWEVER! Note that this literally will check every single patch-line with
"+" at the beginning. Which means that if you fix a simple typo, and the
line had a space at the end before, and you didn't remove it, that's still
considered a "new line with whitespace at the end", even though obviously
the line wasn't really new.

I assume this is what you wanted, and there isn't really any sane
alternatives (you could make the warning activate only for _pure_
additions with no deletions at all in that hunk, but that sounds a bit
insane).

Linus
apply.c