14

我有一个在 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.

看来这是添加这些文件的 TFS 端的提交与添加它们的 Git 端的提交之间的冲突（因为 Git 存储库一开始是空的）。

合乎逻辑的事情可能是跳过这个提交，但是其中有几个文件（比如说几百个中有十个）是新的。当然，这些不会引起冲突。

为什么 Git 不能自己弄清楚这两个文件是相同的？即使我--ignore-whitespace在 rebase 时使用，Git 仍然会显示数十个类似的文件，这些文件似乎是相同的。我不知道如何解决这个问题。

4

4 回答 4

11

正如ebneter评论的那样，它应该是关于行尾差异的。
很久以前我已经详细说明了 git merge 如何不擅长忽略这些差异（与空格差异相反）：
“ git-merge 是否有可能忽略行尾差异？ ”

这就是为什么异构环境中的存储库需要一致的eol 转换策略。
请参阅“使用代码分发 git 配置”。

于 2012-03-30T22:44:48.967 回答
6

我正在做类似的事情，刚刚发现“-X ignore-space-at-eol”。它可用于合并和变基。似乎在做正确的事，但对我来说却是缓慢的死亡。

于 2012-04-14T19:22:36.353 回答
2

如果您可以排除由于不同的行结尾而导致的不可见更改，您可能需要检查文件是否具有不同的模式（例如，如果设置了可执行位）。当文件模式改变时，Git 在 diff 中显示完整文件。

于 2015-02-20T13:52:47.917 回答
1

我刚刚碰到这个问题，然后是这篇文章，只是为了意识到这对我来说也是一个行尾场景。

所以 FWIW，这发生在我的案例中，因为我曾经有“使用 Windows 风格的行尾”，但在某些时候，对于不同的项目，我将它重新配置为“使用 Unix 风格的行尾”（这些配置可从 Git安装程序）。

返回“使用 Windows 样式的行尾”解决了问题而不使用“--ignore-whitespace”

于 2012-06-11T00:00:31.230 回答