If trivial whitespace difference causes wrath fill conflicts then I think you have a deeper issue. I can't think of a situation where this would be even a minor issue.
Not a huge deal, but it hides the actual author of that line when you're doing a blame. I try to only change the precise lines I need to in a commit, and all of them are relevant to the commit message. That way it's usually a very quick check to see what commit added a certain line.
If I absolutely need to do some tidying in a file, I do it in a fully separate commit so that the change can not be construed to be related to the other feature.
hg annotate --help
...
-w --ignore-all-space ignore white space when comparing lines
-b --ignore-space-change ignore changes in the amount of white space
-B --ignore-blank-lines ignore changes whose lines are all blank
If multiple people rearrange the white space at the same time as adding variables (e.g., because the new variables are of types whose names are different widths, both wider than the old gap), you are more likely to get a conflict than if they just leave the spacing alone. Many version control systems seem to tend to do their automated merges line by line, and this sort of edit seems to give them less to work with. [8c99a51796e06219f472f78a5c081dd664da83dc]
Then the wrath comes when you get latest (pull, update, fetch, rebase, call it what you will) and have an inconvenient merge forced on you! I've always personally found the fact that it's just adding or removing white space especially galling :) - but tastes may differ.
If I absolutely need to do some tidying in a file, I do it in a fully separate commit so that the change can not be construed to be related to the other feature.