Hacker News new | past | comments | ask | show | jobs | submit login

FWIW, never heard of it before but I like it.

Meanwhile, a lot of people on these threads would say Automerge is not a CRDT. By definition Automerge.getConflicts means Automerge has conflicts and is not conflict-free.

I on the other hand prefer and applaud Automerge for breaking the rules! I hope it continues to see more success.




I think you are grossly misunderstanding what does and does not make a CRDT. The existence of conflicts is fine - they just need to be solved automatically and in an eventually consistent manner so that all clients come up into the same state once they’re all online. “Conflict-free” refers to there not being any unsolvable conflicts or ambiguity in solving those conflicts. That’s why git isn’t but automerge is:

> The values of properties in a map in automerge can be conflicted if there are concurrent "put" operations to the same key. Automerge chooses one value arbitrarily (but deterministically, any two nodes who have the same set of changes will choose the same value) from the set of conflicting values to present as the value of the key.

> Sometimes you may want to examine these conflicts, in this case you can use getConflicts to get the conflicts for the key.

Basically it’s saying may be you want to look at other “older” values that may have been observed even though the conflict was resolved (eg showing to the user previous copies of the values).


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).


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




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: