undefined | Better HN

0 pointsthe_duke6y ago0 comments

Of course there are still conflicts everywhere.

Developer A makes the button red, developer B changes the label from "OK" to "Accept", both inside the same function.

You can't just pick one or the other, you have to combine the changes.

Or two developers add two different fields to a type. Or ...

Sadly the docs only have placeholders for "Concurrent work and resolving edit conflicts" and "Pull requests and collaboration". Would be very interesting to read the developers thoughts on this.

The system seems to support patches, forking and merging.

0 comments

7 comments · 2 top-level

nadam6y ago· 5 in thread

Hmmm, interesting. It is getting a bit philosophical: you can view it as a conflict. But you can also view it as: hm we have these nice 2 main functions. Let's create a merged one. Kind of what was previously conflict resolution becomes part of regular programming... A slight perspective change.

mbrock6y ago

Mostly they are just not relying on Git for conflict detection and resolution, but bringing it up into the Unison system itself, in order to deal with it more gracefully and intelligently.

xwowsersx6y ago

There's nothing philosophical about it! There will exist a conflict as far as Git (or any other) version control system is concerned. That's all he saying!

SamBam6y ago

My small understanding is that the "(or any other)" part is not correct in your statement, and that you are locked into thinking of version control as being git-like.

I think the implication is that version control is not git like, and that it's not that we both changed the text on line 17, rather we both made additions to the underlying structure.

Indeed, it's impossible for us to both edit the same file, because files are never modified. They are immutable, like a blockchain transaction.

I haven't quite understood how it works in practice, though, but definitely don't think "git".

1 more reply

pwinnski6y ago

That seems to be incorrect. The linked page seems to suggest that both changes will exist without any conflict at the VCS level at all.

2 more replies

strbean6y ago

The files holding the ASTs are append-only. So you get:

PR #1: appended stuff

PR #2: appended stuff

So there is no merge conflict in the git sense.

3 more replies

zawodnaya6y ago

This is the right idea. Conceptually there are conflicts which get resolved in the Unison tooling, but you will never get Git conflicts.

j / k navigate · click thread line to collapse