Hacker News Reader

Comment by theknarf | Hacker News Reader

You can't use CRDTs for version control, having conflicts is the whole point of version control. Sometimes two developers will make changes that fundamentally tries to change the code in two different ways, a merge conflict then leaves it up to the developer who is merging/rebasing to make a choice about the semantics of the program they want to keep. A CRDT would just produce garbage code, its fundamentally the wrong solution. If you want better developer UX for merge conflicts then there are both a bunch of tooling on top of Git, as well as other version control systems, that try to present it in a better way; but that has very little to do with the underlaying datastructure. The very fact that cherry-picking and reverting becomes difficult with this approach should show you that its the wrong approach! Those are really easy operations to do in Git.

View on HN

> You can't use CRDTs for version control

You misunderstand what is being proposed.

Using CRDTs to calculate the results of a merge does not require being allowed to commit the results of that calculation, and doesn't even require that you be able to physically realize the results in the files in your working copy.

Consider for example if you want to track and merge scalar values. Maybe file names if you track renames, maybe file properties if you're not just using a text listing (ie .gitattributes) for that, maybe file content hash to decide whether to actually bother running a line-based merge.

One approach is to use what Wikipedia says is called an OR-set[1], with the restriction that a commit can only have a single unique value; if it was previously in the set then it keeps all the same tags, if it wasn't then it gets a new tag.

That restriction is where the necessity of conflict resolution comes in. It doesn't have to be part of the underlying algorithms, just the interface with the outside world.

[1] https://en.wikipedia.org/wiki/Conflict-free_replicated_data_...

If semantics-layer conflicts still have to be detected somehow, and resolved by hand, what value is the underlying CRDT providing?

> the result is always the same no matter what order branches are merged in — including many branches mashed together by multiple people working independently.

Why is that valuable?

Yeah, symmetry is overrated.

Git's merge is already symmetrical for two branches being merged, and that, in and of itself, often leads to problems.

It's completely unclear that extending this to multiple branches would provide any goodness.

It means anyone can fix the conflict. Including a server side AI.

non sequitur

I was wondering when someone would try to cram The Slop Machine into this.

This was my immediate thought when seeing this post too lol.

Syntax-only manual merges are just time consuming waste of human time.

I'm a small PR-er so 99% of the time it is Syntax. If if it is semnatic at all often then try trunk based development.

The CRDT isn't syntax-aware either

If it is doing what I think CRDT does, and tracking where the user clicked and what they typed, it sort of carries a bit more syntax info. It has a chance to get it right. And often since it does something it turns a figure this shit out with review this.

Much better is AST merging (which itself is also more amenable to crdts). But doing this at the text level is doing to be a failed experiment - the value isn’t there.

Och, hello fellow monotone user.

Pijul does both. It's a VCS, that is a CRDT, that preserves conflicts until a human resolves them.

Look it up: https://pijul.org

It also makes cherrypicking and rebasing wayyyy easier. You can actually add or remove any set of patches, at any time, on any peer. It's a dramatic model shift -- and is awesome.

Both jj and pijul save (~commit) conflicts to be resolved later, rather than require immediate resolution.

And jj was built around rebase being a routine operation, often transparent (cherrypicking being a form of rebasing).

But merging already auto-merges what it can best effort. Conflicts are syntax conflicts not semantic ones.

Therefore you could have automerges that conflict in a way that breaks the code.

Example would be define a global constant in file X. One commit removes it. Another commit on another branch makes use of it in file Y.

OTOH where I get merge conflicts in Git it is usually purely syntax issue that could be solved by a slightly cleverer merge algo. CRDT or semantic merge.

I would like to point out that Bram Cohen seems to be obsessed with “better merges” and had a verbal spat with Linus on Git when it was just taking off (2007).

https://news.ycombinator.com/item?id=8118817

It’s pretty weird that he has gone back to the same idea without understanding why Git’s approach is better. I would say VCS is largely a solved problem. You can simplify a few things here and there, maybe improve support for binaries and few other things, but that’s almost on the top of existing systems. The foundation is rock solid, so it doesn’t sound very sensible to attempt something from ground up.

Reply on news.ycombinator.com