[josephg]

> This is why CRDTs are not more widespread, because they only fix the problem you think you have, not the problem you actually have, which is to fix conflicts in a way that preserves data, its validity and meaning.

I’ve been saying this for years, but there’s no reason you couldn’t make a crdt which emitted conflict ranges like git does. CRDTs have strictly more information than git when merging branches. It should be pretty easy to make a crdt which has a “merge and emit conflicts” mode for merging branches. It’s just nobody has implemented it yet.

(At this point I’ve been saying this for about 5 years. Maybe I need to finally code this up if only to demonstrate it)

[hansworst]

Automerge has this: https://automerge.org/automerge/api-docs/js/functions/getCon...

[josephg]

Reading the docs, it looks like that only works for object keys that have been concurrently set to different values. Not text documents.

[motorest]

> I’ve been saying this for years, but there’s no reason you couldn’t make a crdt which emitted conflict ranges like git does.

I don't get your point. The C in CRDT stands for "conflict-free". Why would a CRDT have conflict ranges?

[josephg]

Because automatic merging isn’t always perfect. Especially when merging long lived changes to code in git, sometimes you need manual intervention to figure out the result. And we need to manually intervene sometimes.

[SkiFire13]

That might be an improvement over git, but not automatically fixing the conflicts will be a dealbreaker for most people.

Fundamentally people want something that automatically fixes conflicts, and do so the way they expect it to, but this just doesn't exist yet.