Section 52.3 Whitespace
Whitespace refers to those pesky characters that you really cannot see visually, but which are definitely (different) bytes in your source code. Spaces, non-breaking spaces, tabs, newlines (carriage return? Enter?). Here is the problem. Somebody else left a blank space at the end of a line mid-sentence, perhaps because they manually added a newline there to make a line shorter and more readable (especially if it is code). Now you open that file with your editor, which is set to strip trailing whitespace from lines. Maybe you make an edit, realize it was not what you needed and remove the edit. The rest of your work is off in some other file. But now the original file has a single one-character deletion, and that will be carried forever in the git history as a change you made to the work of the previous manual-line-breaker.
Solution: the original space introduced at the end of the line in mid-sentence should never have been part of a commit, and should never have been merged in the first place. The fault is really not yours, and having your editor strip trailing whitespace is probably a good thing. But if you find these sorts of mistakes, they should be on a commit of their own, clearly labeled as fixing whitespace (see Section 50.2). But do not be the person who introduces the spurious whitespace in the first place! We will likely ask you to clean it up before your pull request is merged.
Whether or not a newline is the last character of a file seems to be a common “correction” that editors make routinely. Let us say that a newline should be there, so feel free to add such newlines (on its own commit).
When I do
git diff at the command-line, extraneous whitespace (trailing characters, blank lines that are really not at all blank) are shown as bright red rectangles. Can’t miss ’em. Find a similar tool that works for you. Or grep with a pattern like $ (that’s a space and a dollar-sign.) And learn to configure your editor to do the right thing routinely (and no more).
