summaryrefslogtreecommitdiff
path: root/Documentation/git-reset.txt
diff options
context:
space:
mode:
authorLinus Torvalds <torvalds@osdl.org>2006-02-26 09:29:00 -0800
committerJunio C Hamano <junkio@cox.net>2006-02-26 21:54:14 -0800
commit19bfcd5a14e647763e5ecc247ba24790f56721f3 (patch)
tree5ebabd21a44fdec5f7a7e2510efd184f7a932998 /Documentation/git-reset.txt
parentc55f3fff35ac34e6d1f0f686e27029612775e51d (diff)
downloadgit-19bfcd5a14e647763e5ecc247ba24790f56721f3.tar.gz
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
Diffstat (limited to 'Documentation/git-reset.txt')
0 files changed, 0 insertions, 0 deletions