git can already store, diff and merge tree-structured data: directory trees. It would be an interesting experiment to encode various tree-structured data as a directory-tree in git and see how it behaves on different version control operations.
What is suggested in ancestor posts is to change storage format, although I think it better to prototype something like using the above first. Integrating into the object model directly, I suspect one would in the end want to design/evolve a language to build a platform specifically for that. You might end up with something similar to Smalltalk, so would need to think if that's the goal or if there's more to accomplish.
The higher order question is: What concerns need to be integrated, and what concerns need to be separated? Integration may bring new powers, but also risks of evolutions into "big ball of mud". Decoupling may bring freedoms and independency, but also risks of lack of coherency and unoptimal couplings.
What are the benefits of the current paradigm, and what are the disadvantages? CVS and text-files have worked for a very long time, is cross-platform and works beyond any single project scope. Maybe the golang-approach reaches some sort of optimal equilibrium.
Maybe this tool is moving a step towards this goal: https://www.semanticmerge.com/
Smalltalk uses an image and holds live objects in memory at all times - there's no distinction between the source code representation and the running representation of the code. This allows the "IDE" (which is a misnomer because the development environment and the live environment are one and the same) to introspect on live objects and perform analyses on them.
TL;DR; Smalltalk has never used text as an internal representation and that removes the separation between the source code and the debug or live environment.
I feel like the insistence of text based programming languages just leaves the industry completely mired in the mid 1970's.
They only work on the most basic of use cases. The moment you want to get real work done they just get in the way.
Disclaimer: I used to work for one of them (Mendix)
VB6 was so horrible and productive at the same time. Single person could build an app in days that a team of 10 would struggle with today.
And a group of 10 could bring said app to a stretching halt.
So many memories, good and bad.
Was at a company that invented a visual programming tool and forced development to use it.
Several flat out refused. We all went on with our careers. The people that used the proprietary system still work there, not then a decade later. They hated the tool then. But they have no marketable skills set at this point.
Edit: Stay classy HN
But it seems though even mentioning that perhaps structured data is a better way to store code makes most programmers really angry. At least that's my experience.
It's a useful representation model, but really only because programming languages are mostly designed to be line-oriented (though not enough: i.e. Python should disallow multiple imports on one line because it lightly breaks diff-viewing). Git is the dumbest possible thing that can work, and it does work, but it's also wrong.
What we really need is a generic way to store graph-structured data (which is what an AST really is) into something like git. Because then we could finally get rid of the notion of code-formatting as anything but a user experience peculiarity (the rise of "push button and blackbox fixes code for commit" elucidates why this should be).
But more importantly, it would mean we could reasonably start representing commits with some notion of what they are doing to the control flow and structure of the code. Think git's rename detection but it notices when a function is renamed, or can represent refactoring in a diff by showing that all the control linkages of one block of code have moved to a particular function (and by extension, diffs would now implicitly show when new links or dependencies are added).
The trouble of course is doing any of this generically, is an unsolved problem. I have an idea that you could probably do something interesting like this with git's existing structure and a language like Golang, where you decompose the program into a bunch of files representing the hierarchical AST and commit that rather then actual text maybe.