When the git interface shows you 'updates', it's just looking at the contents of different commits and guessing how the files are related. It's not part of the git data model. You could apply the exact same processing to Unison commits.

So the systems work the same way. They make a new object/file based on parent objects. And when it can't create that new object/file automatically, that's called a "conflict".

> No changes are ever made to an existing file,

I did not say or imply that there were. it's a new version, of course.

> so there are never any merge conflicts

Does not follow. There is only one HEAD (latest version) of foo.txt on the master branch. In a merge, it has two (or more) parent objects (1).

> All changes result in a new object/file ... therefore never any merge conflicts.

And yet somehow git calls the process of deciding what's in this new (version of the) file with two parents "resolving a merge conflict". Because the two parent changes can't be automatically reconciled. They are in conflict.

1) https://softwareengineering.stackexchange.com/questions/3142...