In ClearCase evil twin occurs when two files are found with the same name in two different versions of the directory, and If the element OIDs are different but the names are the same.
In GIT the SHA1 id is always unique and file with same name always have different SHA1 id’s.
We don’t have a concept of Evil twins, but there are likely cases where there is chance for 2 or more developers creating a file with different contents with same filename in the same directory. During merge, when both files are completely different, there are chances of the developers to keep his changes alone and leave other changes resulting in code loss.
Can anyone let me know if there will be issues in GIT similar to ClearCase or sine each SHA1 id is unique there won’t be any Evil twin issues in GIT.
Git does tracking at the level of the whole tree, not individual files and directories, so it does not have a concept like an OID.
When merging histories that include incompatible changes to a file (e.g. both added a new file with different contents), Git will produce a merge conflict and stop to let the user resolve the conflict or abort the merge.
Of course, Git can not force the user doing the merge do the right thing, but perhaps it is more difficult to completely ignore one side of the conflict. In Git, the conflict will be in the file itself, not in the directory that holds the file. In other words, the conflict will be about the contents of the file instead of which OID should be linked into the directory. Of course, depending on the tool used, the user may still just press the “take my side in all conflicts”, but Git will not care in the least (though the lazy lout’s boss and coworkers may care very much!).