Does GIT have evil twin issues?

Question

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.

Answer 1

Oh evil twin errors, that takes me back. No you shouldn't have any such errors in git. Git doesn't actually track whole file so much as it tracks chunks of files.

Answer 2

No, but there is a detached head. Sorry, couldn't help myself :)

What would happen is that the file will come up as conflicted when the second developer pulls before doing a push. When files are completely different it will be bleeding obvious that they should have different filenames. The second developer will then do something about (i.e. rename his file so there is no conflict).

Answer 3

Yes, there are some kind of "evil" operation in Git, but not for the same reason than the evil twins of ClearCase:

They are called evil merge:

a merge that introduces changes that do not appear in any parent.

I.e: putting things in the code that no one ever asked to be there, named 'evil merge' because it is difficult corner case for "git blame" to solve when annotating file.
Those merge are generally related to a semantic conflict between the two version merges (and not a simple textual conflict).
A side-effect will be that, instead of adding, removing or modifying a line changed, you end up with both lines, (from the two versions being merged) in the merge result...

Answer 4

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!).