The red blob at the end of the line indicates unnecessary—in Git's "eyes", that is—white-space. Whether certain bits of white-space are unnecessary depends on the user of the data. Consider, e.g., [the Whitespace programming language](https://en.wikipedia.org/wiki/Esoteric_programming_language#Whitespace: trailing blanks are certainly significant here. But since the text in your image is simple SQL, the trailing blanks here are not significant.
This is not necessarily CRLF. Suppose, for instance, that we have the following lines:
This is
some text.
Now let's add the letter Z to the end of each line. The surprise, or not, depending on how carefully you looked at the text above, is that we get this:
This is Z
some text.Z
If we remove the unnecessary blanks after the word is, we would get:
This isZ
some text.Z
If we do strip out these blanks, Git will dutifully show a difference, because there is a difference. It may be a difference without a distinction—as it is in an SQL statement—or not, as it is in the Whitespace language. Git doesn't really know, so it will show the change.
The red (or other color) highlighting depends on both your chosen diff—external diffs, i.e., those not built into Git, will of course just do their own thing—and numerous Git settings. Whether CRs in lines show up or not is also something you can choose, and whether Git whacks on your data to remove CRs, is also something you can configure, but whether or not you configure Git this way, the point at which Git does these changes is not where you expect.1
More interesting to me is this:
\ No newline at end of file
Lines, in a text file, can be separated by line-separators, or terminated by line-separators / terminators. What does this mean? Let's look at the contents of that file with the two lines (after we strip out the silly extra spaces). Does it read This isend-of-linesome text.end-of-line? Or does it read This isend-of-linesome text.? If it's the former, we have line terminators: every line ends with end-of-line. If it's the latter, we have line separators: lines are separated by end-of-line, but the file does not have one final end-of-line.
If we've opened up the file in our editor, maybe we can't tell. Whether, and if so how, we can tell depends on our editor. Very often, though, regardless of which layout the file has—terminators or separators—it will look exactly the same. But it isn't.
The git diff command needs to be able to tell you—or perhaps more importantly, tell Git—when a file is like this. So it uses that \ No newline at end of file to say that the file is missing the final line-terminator. Git, in essence, "believes" that files normally use line terminators and this one is missing one.
If you have a file that ends without a line terminator, and you want to add a line to it, you must add-or-change two lines in the process: you first add a terminator to the one at the end of the file that is missing one, then you add another line, with or without a terminator. If all lines end with a terminator, and you want to add one line, you need only add the one line. So you should probably avoid this situation. There may be a setting in your editor to ensure that the last line of a text file ends with a proper line terminator.
Once you have taken care of that—and checked to see if you added a plain-text blank at the end of the line that used to be the last line of the file—then you can investigate whether you have CRLF issues. See Why isn't my .gitattributes file preventing the addition of "\r"s when checking out files on Windows?, How to normalize working tree line endings in Git?, and more (search for CRLF, line endings, gitattributes, and so on under the git tag.)
1I magically know this by reading your mind. No, of course I don't actually know what you expect, but in practice, nobody seems to expect Git to do it where Git actually does it.
