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.

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.

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!

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

But git works the same way. All files are immutable. All directory trees are immutable. Basically all version control works that way at some level.

Storing data this way doesn't solve the problem of merging the two changes into a new single change. When you can't do that automatically, it's called a conflict.

The only mutable data in git is the list of hashes you've given names to. You can use git without branch names if you want, living in a world of pure immutable hashes. It doesn't do anything to help you get rid of merge conflicts.

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.

That's like saying Git has no conflicts because a file can have different contents in different commits.

A conflict can only arise when trying to unify (aka merge) two different states. The difference is the representation, with Git (naively explained) mapping file paths to text blobs , and Unison mapping identifiers to AST nodes.

Then how do you know which main function to use? That information has to be stored somewhere. Or does the user provide the hash for the main function they wish to run?

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.

It seems to me that if we both edit the same function then we end up with three functions in store (original + two modified). Now obviously I want the main function to call my new version function and you want the main function to call your version. So in the end there is a conflict somewhere - even in the git sense.

If that conflict always shows up in one single line saying what hash of the main function is the one to use - then it doesn’t seem like a huge improvement in terms of conflict handling. Conflicts bubble to the root hash. I assume they thought about this and have some sort of tooling for “traversing” conflicts from the root, choosing my function, your function, or allowing a merged function to be created.

> The files holding the ASTs are append-only. So you get: PR #1: appended stuff PR #2: appended stuff

But that description also applies to git. Which could not avoid having to deal with conflicts.

I disagree: in #1 and #2, the mapping between the key and the function name are different, so there is a conflict.

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