Quoting Junio C Hamano <gitster@xxxxxxxxx> > 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/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html