I feel like I might have explained that badly. In my suggestion, the source code would be diffed as a machine-readable AST tree. That means all source code reformatting actions which do not change the meaning of the source code also do not appear in the diff.

In this explanation about Go:

https://golangdocs.com/golang-ast-package

the text following "and we get a nice structure" is what the source code management tools would be working on. It's an abstract representation of the source code's meaning, but not tied to how things are formatted or indented.

I agree it would (maybe) be better if things had been designed this way from the beginning, but as it is it would be totally incompatible with all existing source code management tools, which is a nonstarter. Even if you can switch to a new editor or IDE, you still have to worry about the GitHub web UI and your error reporting tooling and who even knows what else.

> That means all source code reformatting actions which do not change the meaning of the source code also do not appear in the diff.

The method I described does exactly that. Most modern formatting tools parse code into an AST then rewrite it based formatting rules. So as long as you format both files to the same rules before diffing, only AST changes will show up.

On paper I like this idea. But I can't shake the feeling that every non-text based format I have ever encountered sucks.

And this is how git works with the different newline styles. It can convert them to a single enforced style on commit and converted back when you pull changes.

I've never had that work correctly. Mostly it just gets in the way when the line endings actually matter (because my javascript has to load in IE7).