Git Conflict - Displaying False Positive

I am facing an issue where Git says a file is in conflict when trying to merge, but when I go to resolve the conflict, there is no conflict. Why does Git think it's a conflict when both local and remote are the same? Is there a way for Git to automatically resolve this?

OS: Windows 8

Git Version: 1.9.5

+3


source to share


1 answer


The files don't match exactly.

When GIT detects that the same line / block was changed in two merged branches in a different way, a conflict message is generated. GIT does not attempt to automatically resolve such cases, as their solution is very dependent on the semantics of the file content. GIT doesn't know XML, Java or C #, and not ASN1 syntax and doesn't try to learn them :) These are the very basics.

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

This is why you usually use some kind of external merge utility like TortoiseMerge, WinMerge, KDiff3, etc. They contain several different algorithms / heuristics and they can automatically detect / solve common "trivial" conflicts that are very often solved in the same way or even that are simply ignored as "irrelevant", for example:



  • line end style conflicts (CR vs CRLF vs LF ..)
  • conflicts with spaces only ( 'class Foobar'

    vs 'class Foobar'

    vs ' class Foobar'

    )
  • Encoding conflicts (ASCII vs. UTF8 vs. UTF16)
  • end-of-file conflicts (must have an extra ending line in EOF, not have one)
  • and etc.

Some of these utilities (especially the graphical ones) can show you that the files are "identical" because their apparent text content looks the same even though the raw content of the files is different. It's a matter of preference. When working with clean 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 don't want to see every line changed just because your colleague saved it with CRLF instead of ending with LF.

Three important notes:

  • in such cases, good file merging will not tell you that "the files are identical", but nevertheless, "the contents of the file are identical, but the files are not equal to the binary"; KDiff3 does this for example.
  • spaces / lineaments / encodings / etc. may seem unimportant, but they are not. Take Makefiles or Python for example. There's a huge difference if there is a space or three or a tab.
  • so ignoring whites / encoding / etc is strictly dependent on file usage . In C #, the encoding doesn't matter, in FooBar it can make a lot of difference. This is why GIT doesn't try to impose any kind of automatic handling of such collisions. GIT is safe. File-different or file merge of your choice did this for you and "tricked" you into thinking the files were the same.
+4


source







All Articles