Why does git show a conflict between two apparently identical added files?

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.

Does `diff` give you a difference as well? – Reactormonk Mar 30 '12 at 21:52 — Reactormonk, Mar 30 '12 at 21:52
Could it be line-ending differences? – ebneter Mar 30 '12 at 22:01 — ebneter, Mar 30 '12 at 22:01
"Even if I use `--ignore-whitespace` when I rebase..." – Ryan Lundy Mar 31 '12 at 00:48 — Ryan Lundy, Mar 31 '12 at 00:48

score 11 · Answer 1 · edited May 23 '17 at 12:09

11

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".

edited May 23 '17 at 12:09

Community

1
1

answered Mar 30 '12 at 22:44

VonC

1,042,979
435
3,649
4,283

2

Does Git really consider line-ending differences distinct from whitespace differences!? I thought line endings *were* whitespace! – Ryan Lundy Mar 31 '12 at 00:49
@Kyralessa: not exactly. http://gitster.livejournal.com/28862.html mentions `cr-at-eol`: with `trailing-space`, does not trigger if the character before such a carriage-return is not a whitespace, but it is *not activated by default*. – VonC Mar 31 '12 at 09:22

score 5 · Answer 2 · answered Apr 14 '12 at 19:22

5

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.

answered Apr 14 '12 at 19:22

dpiskyulev

316
2
3

1

Maybe they found a speedup, because for me adding the flag doesn't slow me down. git version 1.9.5.msysgit.0 – AnneTheAgile Apr 16 '15 at 23:44

Alexander · Answer 3 · 2019-11-14T20:36:17.817

2

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.

edited Nov 14 '19 at 20:36

answered Feb 20 '15 at 13:52

Alexander

1,004
5
19

score 1 · Answer 4 · answered Jun 11 '12 at 00:00

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"

Why does git show a conflict between two apparently identical added files?

4 Answers4

Linked