Standard Style in a VCS environment

Recently I have been thinking a lot of the important of standards in regards to programming. I have long felt that people should make the function of their programs perform according to a standard, and that they should make extensive use of contractual programming through interface type mechanisms (which I also view as coding according to a standard). I have not often thought about how the code's style should conform to a particular standard.
A little clarification is in order. By "style" I do not mean c90 vs c99 or Java 6 vs Java 7, but something more like the following.

if(a == b){
    a++;
}
return true;

if(a == b)
     a++;
return true;

In most languages the two sets of statements above are semantically identical, so choosing to write one over the other is generally thought of as matter of preference. Now, I am well aware that there are people out there who lobby, perhaps with good reason, that one style may be superior to another. The hypothetical merits of either method is not what I wish to consider here, but rather the consistency of either one's use. What I really want to address is the consistent use of a particular style in a team environment and more specifically when using Version Control.
If one programmer on a team creates a file according to their own personally, and equally valid, style preferences, it will inevitably be edited by a different programmer with different preferences at some point in the future. Let's suppose that this future programmer, while adding some feature, also changes the file to match his or her preferred style. Then he commits his changes to upstream. This is bad.
Why is this bad? Because the diff for the changes to the file will not include only the new feature related changes of the second programmer, but the all of the semantically meaningless changes to the style of the code. This makes understanding what has actually happened between one commit and another very difficult to discern at a glance.
This may and hopefully does seem obvious to anyone reading this article, but it is not something I had considered until recently.