Of course, the canonical repo may still offend your personal taste. That’s where sourcemaps-aware git extensions come into play, generating mappings between repos based on .style rules…

And that’s *not* a trivial task – indeed, it’s a task that’s orders of magnitude more complex than actually being the version control tool that it’s supposed to be. Even the slightest bug can become a data corruption issue, e.g if it messes up with a whitespace-sensitive language like Python.

When I choose version control system for a project, I usually prefer Mercurial over Git, and the main reason is that the Windows version of Git has turned on core.autocrlf by default. It creates all sorts of problems when somebody not on Windows has created a repository, and when you check it out on Windows, “git status” immediately reports all files as changed, and you cannot “git pull” because of all the uncommitted changes, yet when you try to “git commit”, you cannot do that either, because there are no changes to commit. Of course I turn off core.autocrlf in my local Git installation, but dealing with people who haven’t done the same is so annoying that I prefer not using Git.

The fundamental problem is that Git breaks the principle of “do one thing and do it well”. End of line characters is not a version control task and should not be done by a version control system. It is a text editing task, and it should be handled by your code editor/IDE. Unfortunately most code editors and IDEs do so horribly (just like they often fail to have sensible handling of character encodings and similar things). But poor code editors is no good excuse for doing a code editor’s job in a VCS.

Some code editors and IDEs actually do a pretty good job of whitespace formatting. For example in Eclipse, Ctrl+Shift+F works very well. But it is not perfect. It does not support using different formatting rules for saving versus displaying, which is what you want here, but I personally don’t really care what whitespace formatting rule I use, as long as it is consistent within a project. The Eclipse formatter also does not support saving the rules in a standardized IDE independent format. But the fix should be to improve the IDE functionality, not to add IDE functionality to the VCS.

https://www.kernel.org/doc/Documentation/CodingStyle

function repeatTenTimes (fn) {
for (var ix = 0; ix < 10; ix++) {
fn();
}
}

function repeatTenTimes (fn) {
var ix;
for (ix = 0; ix < 10; ix++) {
fn();
}
}

Not to mention variable names, which loop type to use, ect.

Whitespace is only a small portion of the information in a file that can vary without actually affecting the code that gets written.

Also, how does git know whether whitespace is significant or not?

Take a look at clean/smudge filters (https://www.kernel.org/pub/software/scm/git/docs/gitattributes.html), they can be used to automatically clean up files when checking them in/out.