> Yes, philosophically there is a conflict, which is resolved by you deciding which main() function you find more useful.
it's not just philosophical though. In git terms, when merging the two sets of changes, someone has to choose which of these functions goes onto the master branch. git calls this a "merge conflict".
No changes are ever made to an existing file, so there are never any merge conflicts. All changes result in a new object/file, named based on a content hash.
So in git terms, there are never any updates, only additions, and therefore never any merge conflicts.
Git doesn't store updates or additions. It only stores new objects/files, named based on a content hash.
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".
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.
it's not just philosophical though. In git terms, when merging the two sets of changes, someone has to choose which of these functions goes onto the master branch. git calls this a "merge conflict".