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'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?
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.
