为什么git在两个明显相同的添加文件之间显示冲突?

Rya*_*ndy 11 git git-rebase merge-conflict-resolution git-cherry-pick

我有一个在TFS中启动的项目,然后转移到Git.不幸的是,将它移动到Git的人只是检查当前文件而不是使用git-tfs.我试图在我使用git-tfs从TFS中提取的提交之后,在Git中重新设置他的新提交.

要做到这一点,我只是简单地在git-tfs提交之上重新提交他的提交.(我意识到这会弄乱远程Git分支机构,但我们是一个小团队,它会没事.我也尝试过挑选樱桃,但我遇到了同样的问题.)

我遇到的问题是一组看起来像这样的冲突:

<<<<<<< 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.
Run Code Online (Sandbox Code Playgroud)

看来这是添加这些文件的TFS端提交和添加它们的Git端提交之间的冲突(因为Git repo开始为空).

逻辑上可能是跳过这个提交,但也有一些文件(比如几百个中的十个)是新的.当然,那些不会引起冲突.

为什么Git不能自己弄清楚两个文件是否相同?即使我在使用--ignore-whitespacerebase时使用,Git仍会显示几十个这样看似相同的文件.我对如何解决这个问题感到茫然.

Von*_*onC 9

它应该是关于线路结束的差异,正如ebneter评论.
我很久以前就已经详细介绍了git merge如何不擅长忽略这些差异(与空格差异相对):
" git-merge是否有可能忽略行尾差异? "

这就是异构环境中那些存储库需要一致的 eol转换策略的原因.
请参阅" 使用代码分发git配置 ".

  • Git 是否真的考虑了行尾差异与空格差异的区别!?我认为行尾*是*空格! (2认同)

dpi*_*lev 5

我正在做类似的事情,只是发现了"-X ignore-space-at-eol".它可用于merge和rebase.似乎正在做正确的事,但对我来说死亡很慢.