[Bug?] "diff -B --color" output doesn't show space errors

[Nanako Shiraishi <nanako3@lavabit.com>]

Quoting Junio C Hamano <gitster@pobox.com>

> By default, if the pathname that was present in the old version still
> appears in the new version, that path is not considered as a candiate
> for rename detection.  Only "X used to be there but is gone" and "Y did
> not exist but appeared" are paired up and checked if they are similar.
>
> Give the command -B option, too, to break the filepair that does not
> disappear.

I wanted to try this -B option, and wrote a little test program.

While it shows correctly that the file was rewritten, it doesn't
point out various whitespace mistakes in the file anymore.

Is this a bug, or should I give some other options as well?

-- >8 -- cut here -- 8< --
git init

cat >file <<"EOF"
This is an article that will be
completely rewritten in a
later commit.
EOF

git add file

sed -e "s/T/\t/g" -e "s/_/ /g" >file <<"EOF"
An article was written but it was_
later rewritten to be_
a completely different text.
_____
An article was written but it was_
later rewritten to be_
a completely different text.

An article was written but it was_
later rewritten to be_
a completely different text.

Worse yet, the replacement text_
introduces a lot of
_Twhite space errors_
such as SP before HT and trailing
whitespaces, when the file was modified by the 
later commit.

Also there are trailing empty lines at the end of the file.



EOF

git diff --color
git diff --color -B
# end of test program

-- 
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/