Hacker News Reader

Comment by yazaddaruvala | Hacker News Reader

https://automerge.org/docs/documents/conflicts/

"The only case Automerge cannot handle automatically, because there is no well-defined resolution, is when users concurrently update the same property in the same object (or, similarly, the same index in the same list). In this case, Automerge picks one of the concurrently written values as the "winner", and it ensures that this winner is the same on all nodes"

"The object returned by getConflicts contains the conflicting values, both the "winner" and any "losers". You might use the information in the conflicts object to show the conflict in the user interface."

To me, this seems identical to how git works. Specifically git fetch (does automatic resolution storing all of the changes), vs git merge (showing the conflicts in the user interface).

View on HN

Automerge is "conflict-free" by the definition of "conflict-free" used in CRDTs. i.e. conflicts are automatically resolved in the same way every time by the algorithm. The .getConflicts allows you a neat interface to inspect a concurrent change to the same value. There is no conflict, no failure to merge. It automatically merges as usual. If you choose to act on the information returned by .getConflicts then that is a new change, it does not alter the past.

If you fetch from a repo with a slightly different history for a named branch than what you have locally, git fetch will fail. Thus git fetch operations are not part of a CRDT.

Similarly, the order in which you synchronize (fetch or merge) from remote sources is order dependent and does not eventually converge to the same result (e.g. the commit hashes will diverge for a simple reason that the current time is part of the commit hash).

This is even more true for git merge which does not even attempt automatic conflict resolution if the same file is edited multiple times.

Automatic conflict resolution is a key requirement of CRDTs and another is that when nodes are brought online they are guaranteed to converge to the exact same state. This is demonstrably not true for git & trying to handwave it away doesn't change anything.

Not sure why you're trying to shoehorn git into the CRDT definition when it's its own thing.

> What I'm describing here is very similar to decentralized version control (e.g., git and mercurial). In git, you commit locally and eventually merge and push your changes into a remote repository. Unlike git, CRDTs don't have merge conflicts. Conflict resolution is handled by the CRDT algorithm itself. Although not exactly a CRDT, git will be a useful model to refer back to since it is something already familiar to most developers and incorporates similar concepts.

https://vlcn.io/blog/intro-to-crdts

Reply on news.ycombinator.com