As I said above, I imagine keeping commits. Think of them like checkpoints in a race. Any typed character will be between two commits - so git log and git blame

As I said above, I imagine keeping commits. Think of them like checkpoints in a race. Any typed character will be between two commits - so git log and git blame can still work just fine. They just operate on a different data structure internally. Merging is also fine. How do you think CRDTs work? You know merging is the entire point, right? I agree that the system needs to handle both synchronous edits (peer programming) and asynchronous edits (the kind of editing we do now with git). CRDTs can handle separate concurrent branches just fine. It’s just none of the existing crdt libraries support branches. You’re right that rebase is weird in CRDTs, but I think we can still build it if we need to. Rebase is mostly used in git to work around one of git’s design flaws: Git is never sure if commits should represent the actual history of changes, or the semantic history of merged tickets. But a better system could just separate those ideas anyway. Yes, it is a PhD level problem right now. But so was diff-match-patch a few years ago. I’m an expect in this field. And I believe we now know how to solve all the sub problems here - all but one: how do we actively generate conflicts from asynchronous edits in a crdt? That needs to be figured out first.