Why does git show a conflict between two apparentl

Question

I have a project that was started in TFS, then moved to Git. Unfortunately, the guy who moved it to Git just checked in the current files instead of using git-tfs. I'm trying to rebase his new commits in Git on top of the commits I pulled from TFS using git-tfs.

To do this, I'm simply rebasing his commits on top of the git-tfs commits. (I realize this will mess up remote Git branches, but we're a small team and it'll be OK. I've also tried cherry-picking instead but I hit the same problem.)

The problem I'm running into is a set of conflicts that look like this:

<<<<<<< HEAD
namespace OurNiftyProject
{
    public enum CardType
    { 
        Visa = 0,
        MasterCard = 1
    }
}
||||||| merged common ancestors
=======
namespace OurNiftyProject
{
    public enum CardType
    { 
        Visa = 0,
        MasterCard = 1
    }
}
>>>>>>> Add a bunch of stuff.

It appears that this is a conflict between a commit from the TFS side that added these files, and a commit on the Git side that added them (as the Git repo started out empty).

The logical thing would be to skip this commit, perhaps, but there are a few files in it (say ten out of a couple hundred) that are new. Those don't cause conflicts, of course.

Why can't Git figure out on its own that the two files are identical? Even if I use --ignore-whitespace when I rebase, Git still shows dozens of files like this that appear to be identical. I'm at a loss for how to resolve this.

Answer 1

I'm doing a similar thing and just found out "-X ignore-space-at-eol". It is available for both merge and rebase. Seems to be doing the right thing but makes it death slow for me.

Answer 2

It should be about line-ending differences, as ebneter comments.
I have already detailed a long time ago how git merge wasn't good at ignoring those differences (as opposed to whitespaces differences):
"Is it possible for git-merge to ignore line-ending differences?"

That is why a consistent eol conversion policy is necessary for those repository on heterogeneous environment.
See "Distributing git configuration with the code".

Answer 3

I just bumped into this issue, followed by this post just to realize it's a line-ending scenario for me as well.

So FWIW, this happened in my case because I used to have "Use Windows style line endings", but at some point, for a different project, I reconfigured it to "Use Unix style line endings" (these configurations are available from the Git Setup program).

Returning to "Use Windows style line endings" solved the problem without using "--ignore-whitespace"

Answer 4

If you can rule out invisible changes due to different line endings, you may want to check if the files have different modes (e.g. if the executable bit is set). Git shows the full file in a diff when the file mode changed.