1

带有 Cygwin 的 Windows 上的 Git 充满了危险。然而，有一个真的开始困扰我。

它与 core.autocrlf=true 行为有关。在花了一周的时间在网上拖网之后，很明显你会遇到的问题没有那么糟糕了。但是，如果文件末尾有一行带有空格的行，则似乎会造成重大问题。

问题是 git 认为文件有本地修改，即使它没有。例如，在全新克隆之后，“git status”或“git diff”将立即显示任何此类文件已修改。'git reset --hard' 完成了它的工作，但这些文件仍然显示为已修改。'git diff' 将差异显示为“删除了一个空行，添加了一个空行”。

问题是，这会阻止 git pull！

$ git pull
Updating 73bcc56..dba6253
error: Entry 'foo.py' not uptodate. Cannot merge.
$ git reset --hard
HEAD is now at 73bcc56 ...
$ git diff
diff --git a/foo.py b/foo.py
index 4cc3854..ccde3f6 100644
--- a/foo.py
+++ b/foo.py
@@ -14,7 +14,7 @@ class TestHelpFunctions(unittest.TestCase):
     def testVersion(self):
         v = sendCommand("version")
         self.assertEqual(len(v), 2)
-
+

好的，我认为 - 方式发生了局部变化。如果我把它藏起来怎么办？不 - 在 git stash 之后，它仍然将此文件显示为本地更改。

好的，如果我添加它呢？当然，这仍然会阻止拉动：

$ git add foo.py
$ git pull
Updating 73bcc56..dba6253
error: Entry 'foo.py' would be overwritten by merge. Cannot merge.

好的，最后一次尝试 - 让我们提交它并完成它。哦，太好了，这个文件有冲突。但令人惊奇的是，该文件没有冲突标记！不幸的是，'git pull' 现在抱怨我正处于冲突合并的中间，即使没有标记冲突。

我发现，解决方法是永远不要在换行符之前提交带有尾随空格的文件。它只是让 git 认为文件被修改了，而实际上它没有被修改，这可能是由于 DOS-UNIX 行结束逻辑显然被破坏了。

无论如何，我并不是真的在寻找答案，因为最后我只是对整个事情进行了核爆并重新克隆。我真正想知道的是，任何人在尝试将 git 与 Cygwin 一起使用时如何保持理智。

当目录被称为“FOO”时，不要让我开始使用“git add foo/a foo/b FOO/c”...

4

1 回答 1

2

根据我的经验，我所有的文件都使用 UNIX eol 样式，并且我一直将其设置core.autocrlf为 false。
看到这个答案

任何“自动”发生的事情，尤其是在分布式环境中（您不能保证在远程存储库上进行相同的设置）都是在自找麻烦。

基本上，如果您的工具（如用于 merge的工具）设置正确，它们将处理任何空间/eol 问题。不是直接Git。

于 2009-10-21T05:59:06.997 回答