3 ms·
Does this make it difficult to do the "blame" thing that Github does to see which commit created which line of code?
by Buge 12y ago
Does this make it difficult to do the "blame" thing that Github does to see which commit created which line of code?
- ygra 12y agoIt makes it difficult in any VCS or diff tool, by default. However they can usually instructed to ignore white-space changes. As an example, in hg I have the following three revisions of a file: abc def ghi abc deg gHi abc d eg gHi Different invocations of hg annotate yield different results, then: > hg blame a.txt 0: abc 2: d eg 2: gHi > hg blame -b a.txt 0: abc 2: d eg 1: gHi > hg blame -w a.txt 0: abc 1: d eg 1: gHi -b ignores changes in the amount of white-space if there was already some (e.g. indenting changes). -w ignores all white-space changes. Generally you can get back to the actual revision where a useful change was made.
- ketralnis 12y agoIt breaks the at-a-glance blame. But the blame output looks like this: Bob | abcdefg (Changed some whitespace) | def my_function(): Bob | abcdefg (Changed some whitespace) | return whatever() So if you really want to know the history of a function, you can just click the revision number to get to the rest of the history. And it's not just whitespace changes that do this, of course. Any refectoring work, splitting files, renaming functions, etc will do it too.