starts with “based on the fundamentally sound approach of using CRDTs for version control”. How on earth is crdt a sound base for a version control system? This makes no sense fundamentally, you need to reach a consistent state that is what you intended not what some crdt decided and jj shows you can do that also without blocking on merges but with first level conflicts that need to be resolved. ai and language aware merge drivers are helping so much here i really wonder if the world these “replace version control” projects were made for still exists at all.

▲

nozzlegear 5 hours ago | parent | next [-]

> ai and language aware merge drivers are helping so much here i really wonder if the world these “replace version control” projects were made for still exists at all.

I really wonder what kinds of magical AI you're using, because in my experience, Claude Code chokes and chokes hard on complex rebases/merge conflicts to the point that I couldn't trust it anymore.

▲

miloignis 6 hours ago | parent | prev [-]

The rest of the article shows exactly how a CRDT is a sound base for a version control system, with "conflicts" and all.

	▲	jFriedensreich 27 minutes ago \| parent \| next [-]
		where?
	▲	skydhash 5 hours ago \| parent \| prev [-]
		But the presentation does not show how it resolves conflicts. For the first example, Git has the 3 way-merge that shows the same kind of info. And a conflict is not only to show that two people have worked on a file. More often than not, it highlight a semantic changes that happened differently in two instances and it's a nice signal to pay attention to this area. But a lot of people takes merge conflicts as some kind of nuisance that prevents them from doing their job (more often due to the opinion that their version is the only good one).