[m12k]

I used to think the future of version control was semantic: E.g. I renamed a method, while someone else concurrently added another call to that (now differently named) method. Git doesn't catch this, nor would this new system. The solution seems obvious to a human: Use the new name at the new call-site too. But it requires operating at the level of the semantic meaning of a change, and not just the dumb textual changes. I used to think this would require a new version control system that encodes the semantics of the changes in the commits, in order to have them available at merge-time. But these days, it seems much more realistic to stick to git, but loop in LLMs when merging, to re-create the semantics from the textual changes.

[bilekas]

This is more than just a version control though, they only thing any VC uses that's important is the diff and the timestamps, you would be adding in project context awareness which is a whole other thing.

I'm sure there are smarter people than me who could create some hooks to automagically update those references on merge/rebase though. Not sure I would pay a whole LLM each time personally.

[WolfeReader]

Darcs did this decades ago with the "replace" command. It's not a legitimate semantic replacement, though - it's more just telling your VCS to do a find/replace.

[gnufx]

As far as I remember, that's just because only the find/replace was implemented, and it could have more sophisticated (semantic?) features.

[cush]

> I renamed a method, while someone else concurrently added another call to that

This is the most common use case for any compiler or linter