On Thu, Oct 19, 2017 at 02:15:12PM -0700, Stefan Beller wrote: > > +test_expect_failure 'move detection ignoring whitespace at eol' ' > > + git reset --hard && > > + # Lines 6-9 have new eol whitespace, but 9 also has it in the middle > > + q_to_tab <<-\EOF >lines.txt && > > + long line 6Q > > + long line 7Q > > + long line 8Q > > + longQline 9Q > > + line 1 > > + line 2 > > + line 3 > > + line 4 > > + line 5 > > + EOF > > + > > + # avoid cluttering the output with complaints about our eol whitespace > > + test_config core.whitespace -blank-at-eol && > > We avoid the eol space change as we want to test the move detection > without interference. Do we want to test it with that as well? I don't think it creates interference. It's just that the expected output becomes more like: <CYAN>+<RESET><CYAN>long line 6<RESET><BLUE> </RESET> and the extra coloring just made it harder for me to read and write the test. :) I agree it might be worth checking the interaction between whitespace coloring and --color-moved, but I think we'd want it to be more thorough (e.g., covering the beginning of line with indent-with-non-tab or similar). > The commit message really enlightened me, > Thanks! Thanks for reviewing. -Peff
