[Dewie]

I don't why the committer can't leave a message like:

> Formatting change. Use `wdiff` to confirm that changes are just stylistic

The reviewer runs `wdiff` and confirms that the commit is just a formatting change. If the language is not layout-aware, then he will know that none of the changes are "semantic". Now he can look over the changed lines themselves (not necessarily with `diff`; just looking at the changed lines themselves) and see if the change is worth it/in line with the project.

PS: Maybe there should be a "column diff", something that checks that one file uses the same alignment as another file. I'm not able to show it here since HN will truncate spaces between words ( ;) ), but the point is to check if two files uses the same alignment, for example that in

> var v = 12

the next variable declaration, the numbers line up. I don't know if that is worth it, and the check would only be valid for some parts of the files.

[andreasvc]

Sure the reviewer could run `wdiff`, but it's an extra manual step due to a completely cosmetic and useless formatting style. If you're perusing hundreds of diffs, deciding when to applying whitespace significant vs insignificant diffs is a distraction, and it can't be done automatically.

You can fantasize about better diffs. Why isn't a diff applied directly to the abstract syntax trees of a language, for example? However, I think part of the robustness of version control systems comes from keeping things simple, namely line-based diffs, and with that comes a preference for keeping line-based diffs short.