[josephg]

Yeah; and the merging is correct in all cases. You don't get spurious conflicts like you can with git.

Also the same system can work both in realtime and offline scenarios. And CRDTs can handle a lot more than just plain text editing.

That said, one thing git does that I like is that sometimes I want conflict markers to be added to my document when concurrent edits happen on the same line. CRDTs (and REGs like this) store strictly more information than git does, so theoretically it should be possible to make a CRDT which adds conflict markers too like git does. But as far as I know, nobody has built that yet! I really hope someone does, because it would be really neat.

I really want a git style version control system built on top of CRDTs with optional merge conflicts.

[bmacho]

> Yeah; and the merging is correct in all cases.

No, it's obviously not.

I'd say most of the time the merging is incorrect, that is, it is in contrast to both of the parties intention. Unlike git, which actually notifies them, Loro just silently modifies both changes into something nonsense/wrong.

[josephg]

My correctness point is that Git can end up with commits which spuriously conflict with themselves. Git's merge algorithms simply aren't very good.

CRDTs (and REG) are correct in that everyone always ends up seeing the same document state. But I take your point - which is essentially that Loro (and automerge, yjs, diamond types, etc) don't correctly preserve intent in all cases. As you point out, if two users concurrently edit the same word, you can get nonsense.

In practice thats usually fine when users edit in realtime - since users notice and fix it. But its often not ok while users edit asyncronously (eg while offline). Thats exactly why I want a CRDT type system which can emit git style conflicts.

[cubefox]

A while ago we would have said a computer program obviously can't guess the intent behind edits. But now we do have such programs: Language models. I wonder whether anyone has already used one to automatically solve merge conflicts.

[josephg]

That’s a good idea that I’ve heard a lot of people suggest. But as far as I know nobody has actually implemented merging using a llm yet.

Part of the problem is that CRDTs want to have strong eventual consistency - so, after merging everyone should be looking at the same final result. It’s hard to guarantee that if you pass the conflicting data to a LLM.

[rubymamis]

Exactly. This process of putting users in control by notifying them about changes and allowing them to decide how to merge is essential when dealing with text.

It sounds like Loro can do that too, but then again, is it worth the complexity over git?

[WorldMaker]

darcs [0] patch theory was a predecessor to OTs/CRDTs (and a predecessor to git as well; in some ways it is the "smart" to which git was named "dumb"). When it works and performs well it is still sometimes version control magic.

pijul [1] is an interesting experiment to watch, trying to keep the patch theory flag flying and also trying to bring in updates from OTs and CRDTs as it can.

[0] https://darcs.net

[1] https://pijul.org/

[cubefox]

What's more realistic: Git switching to some form of CRDT, or Git being superseded by a different system which is based on CRDTs?