[arkh]

> replaces Git with a new idea about versioning

With the advent of LSP I feel like we're almost to a point where you could version structures and not code. Like being able to follow how some class / method got cut in multiple pieces during a refactoring round.

Or maybe we need something more than plaintext to store code and the meta data around it before we can get to this point. I'm sure it has been already done multiple times in different ecosystems but there must be a way to standardize the information about code and use it in IDE and versioning tools.

[martinvonz]

You might find Unison interesting: https://www.unison-lang.org/docs/the-big-idea/

[codethief]

Also, https://scrapscript.org/

[ozim]

Problem is metadata is taking much more time/space to fill in and context to be encoded will be awful lot of typing for a person.

When writing code context is encoded in the code and if you start on new project you need to read documentation and ask people around to pass you the context so you don’t need metadata. Or so to say all stuff that is in tickets and documentation plus what is in other teammates heads.

There’s just no way it will be efficient to somehow drop all of it while you want to do the code.

[zokier]

Things like difftastic work perfectly fine with git

https://difftastic.wilfred.me.uk/

[arkh]

Let's say I have a methodA somewhere in my code.

I decide to rename it and add a parameter: my IDE knows what I'm doing as it can change the new name everywhere the method is used. My versioning tool not so much: it can tell me some lines changed but it does not expose the fact "methodA has been renamed to superMethodB", that's something the user has to put in a commit file.

Add a moment when this method is refactored as 2 new methods and it starts being harder to follow in diff files. Most code forges already link commits to tickets: why not be able to directly link code constructs changes to tickets to telemetry artifacts? Mostly hidden through the IDE "task" management but all present in whatever ends in versioning. You could get git blame on steroids.

[rswail]

Store ASTs in git instead of text, "reconstruct" the text when displaying to the developer and roundtrip.

Add some execution context and annotations to the AST and you could even do "git blame" in your debugger.

[zokier]

code can be thought of as serialized ast, and you need to serialize ast somehow anyways for storage

[rswail]

Yes and no, code comes with affordances like whitespace and comment layouts that are for humans that are unnecessary excess for ASTs.

[chrishill89]

> Or maybe we need something more than plaintext to store code and the meta data around it before we can get to this point. I'm sure it has been already done multiple times in different ecosystems but there must be a way to standardize the information about code and use it in IDE and versioning tools.

This idea of storing more structured information (in the VCS or on disk) keeps coming up but I don't think it's necessary at all. The disk and the VCS can stay dumb. You can reconstruct the rich information after the fact.

It boils down to storing the right information and extracting it. Maybe you want to guard some checkpoints from bad/unstructured data. But that's just a check[1]. The serialization can be simple.

Well say you are blocked from storing bad data (according to the structure). Say you can also detect refactors like code moves (better than Git does, I guess just line moves). Again the storage can be dumb so that's fine. But you still need intentional commits; you won't get helped by a 500-line diff where all kinds of back and forth to solve three and half separate concerns are buried.

First of all you need good data in order to have something to extract. Which requires commit discipline.

[1]: And you don't get much from storing in a more rich format by itself. Just that you committed/stored syntactically correct/compilable artifacts. That's not nearly as rich as what you want. Because there are thousands of different intents (like you allude to) like refactorings -- all are valid in their own way so the structured representation can't have an opinion on it.