Following this problem I now have two local git repos on my windows machine that I want to merge. When I use the WinMerge tool to compare files in the repos, the differences are shown corectly. But when git tries to merge the entire file is marked as conflicted.
One important point is that there are other files which are identical and are correctly processed. Another point is that the problem has nothing to do with core.autocrlf for two reasons: 1- I tested with both true and false settings 2- WinMerge shows no difference with ignore line endings option off
How do you suggest we investigate this matter?
[edit] I upgraded git but it was no use.
When Git performs a normal merge, it considers exactly three points: the two heads you're merging, and the merge base, which is usually the nearest common ancestor. If you're merging unrelated histories, this common ancestor is the empty tree; that is, the state with no files.
A merge takes the sum of the result of applying the differences between the merge base and each head.
If, on merge, the file is identical on both sides (that is, the blob has the same object ID), then the result of the merge is simply to take that blob as the value for that file during the merge. Both sides share identical changes, so there's no point in doing any fancy analysis. This explains why identical files work just fine for you in this case.
However, in the case where the files are not identical and you have unrelated histories, Git considers this an add/add conflict: that is, one side has added some set of lines and the other side has added another set of lines. It may be the case that many of these lines are in common, but the conflict is logically the fact that two different sets of lines are added, so the entire file conflicts.
This is why merging independent histories of the same codebase tends to be a bad idea. You can either resolve the conflicts by hand, or you can perform a merge of two identical states of the repository, which will result in a conflict-free merge, and then merge your changes again in a second merge. In the latter case, your merge base will not be the empty tree, but the identical merged state, and as a result, Git will be able to resolve the changes much better without conflicts.