>I agree Git Blame is useful, but squash on merge is great, and having atomic commits for whiteline changes is overkill. FWIW this is something you see commonl

>I agree Git Blame is useful, but squash on merge is great, and having atomic commits for whiteline changes is overkill. FWIW this is something you see commonly on mailinglists. Each line you modify in a given commit is assumed to be specifically related to the change described in the commit description. It's just easier for reviewers when you break whitespace changes or non-semantic text changes out into separate commits so that they don't have to try and figure out which lines are semantic changes and which aren't. Given that people who work with patchsets tend to do a lot of rebasing in their workflows, they are generally familiar enough with rebasing to just split out a set of changes from a given commit into two commits in a minute or less.