Could the next-gen version control system just store ASTs? Does this already exist?
Every user gets their own preferred formatting, and linters and tools could operate on already-parsed trees
Every user gets their own preferred formatting, and linters and tools could operate on already-parsed trees
The thing is that this means sacrificing the enormous advantage of plaintext, which is that it is enormously interoperable: we use a huge quantity of text-based tools to work with source code, including non-code-specific ones (grep, sed…)
Also, code is meant to be read by humans: things like alignement and line returns really do matter (although opinions often differ about the “right” way)
And of course the lesser (?) problem of invalid ASTs.
I know a lot of people think source control should only have buildable code, but that's what CI processes are for and people use source control (and diffs) for a lot of things that don't need to pass CI 100% of the time.
That may be fine if you are happy with the plain text status quo, but if your goal is to avoid or minimize merge conflicts (as most people want when talking about semantic diff), you don't really solve that as well as you'd like.
(Additionally, and it is a lot less of a concern for git on disk storage but for some git-based email flows and other VCSes patch size matters and a consistent style of diffs between patches can be a useful storage or transfer optimization. Plain text diffs are more likely to produce a lot bigger patches compared to optimization wins you might get from a semantic diff; a mixture of merges between semantic and plain text diffs is often a worst of both worlds case in overall patch sizes as they churn against each other.)