> GIT is already best model for keeping history of textual changesNo it’s not. Git isn’t a model of textual changes. It’s just a model of textual snapshots connected over time.If I were building a replacement for git, it would store character by character changes instead - though for that to work properly you’d want editor integration. Then the same tool could act as both a version control system and as a platform for realtime collaborative editing (via CRDTs). You can still have commits - they’re essentially just tags. And I’d keep the concept of branches.Most of the algorithmic work has already been done - at least from the CS research side. Combine my work in diamond types with some of Martin Kleppmann’s work on BFT CRDTs & automerge. There’s a few more tricks needed. For example, you don’t want a hash on disk per keystroke. I’ve figured out a nice answer for that but haven’t written it up yet.Deleting data is an unsolved problem. For example, if someone accidentally pastes in a password you need a way to prune it from the history. And async merges probably want to emit conflicts - which nobody has done on top of CRDTs yet as far as I know.If I were building it, I’d also throw in a simple crdt based data store, synced over the same protocol. Then we could also store GitHub issues and other stuff inside the repository itself (a la fossil). CRDTs resolve conflicts better than git ever will, because they have access to more information than git does about what happened.It’d be a pretty cool model. Definitely worthy as a successor to git in my opinion.