Git Conflict -- Showing False Positive

Question

I'm running into an issue where Git will say that a file is in conflict when trying to do a merge, but when I go to resolve the conflict, there's no conflict. Why does Git think it's a conflict when both the local and the remote are the same? Is there a way to have Git automatically resolve this?

OS: Windows 8

Git Version: 1.9.5

Answer 1

The files are for sure not the same.

When GIT detects that the same line/block was changed in two merged branches a different way, raises a conflict message. Git doesn't try to solve such cases automatically, since solving them is very much dependent on the semantics of the file's contents. Git does not know XML nor Java nor C# not ASN1 syntax and does not try to learn them :) That's the very very basics.

However, some conflicts are "trivial" for you as a programmer.

That's why you usually use some external merge utility like TortoiseMerge, WinMerge, KDiff3, etc. Those contain some different algorithms/heuristics, and those happen to be able to automatically detect/solve common "trivial" conflicts that are very often solved in the same way, or even, that are simply ignored as "unimportant", for example:

• line ending style conflicts (CR vs CRLF vs LF ..)
• whitespace-only conflicts ('class Foobar' vs 'class Foobar' vs ' class Foobar')
• encoding conflicts (ASCII vs UTF8 vs UTF16)
• end-of-file conflicts (should have extra endline on EOF vs not have it)
• etc.

Some of those utilities (especially graphical ones) may show you that files are "identical" because their apparent textual content looks to be identical, even if the raw contents of the files are different. This is a matter of preference. When working with pure code files, it usually doesn't matter if your Java or C# file is saved as UTF16 or UTF8 - you are interested in code differences. You often wouldn't like to see that every line was changed just because your colleague saved it with CRLF instead of LF ending.

Three important notes though:

1. in such cases, a good file-merger will notify you not that "files are identical", but i.e. that "file contents are identical, but files are not binary equal"; KDiff3 does that for example.
2. whitespaces/lineendings/encodings/etc may seem unimportant, but they are not. Take for example Makefiles or Python. There's huge difference if there's a space or three or a tab.
3. therefore, ignoring whites/encoding/etc is strictly dependent on the usage of the file. In C# encoding may matter not, in FooBar it may matter much. That's why GIT does not try to impose any automatic handling of such collisions. Git plays it safe. The file-differ or file-merger of your choice did that for you and "fooled" you into thinking that files were the same.