Question

Windows上的Git与Cygwin充满了危险。然而，有一个真的开始让我烦恼。

它与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行结束逻辑明显被破坏了。

无论如何，我并不是真的在寻找答案，因为最后我只是把整个事情都搞砸了。我真正想知道的是，在尝试与Cygwin一起使用git时，人们如何保持理智。

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

Answer 1

根据我的经验，我的所有文件都使用UNIX eol样式，并且我始终将core.autocrlf设置为false。见SO answer

发生“automagically”的任何事情，尤其是在分布式环境中（您无法保证远程存储库上的相同设置）都会遇到麻烦。

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

git＆amp; Cygwin - 尾随空格导致“不上传”

1 个答案: