3 ms·
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. S
by pwinnski 7y ago
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.
- SideburnsOfDoom 7y agoOk, if you want to be pedantic, lets be pedantic: > 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/314215/can-a-git-commit-have-more-than-2-parents https://softwareengineering.stackexchange.com/questions/3142...
- Dylan16807 7y agoGit 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".