git& Cygwin - 尾随空白导致“不uptodate” [英] git & Cygwin - trailing whitespace causes "not uptodate"

问题描述

Git在Windows w / Cygwin充满危险。但是有一个真正开始对我造成损害。

Git on Windows w/ Cygwin is fraught with dangers. However there's one that's really starting to bug me.

这与core.autocrlf = true行为有关。在花了一个星期拖网的后，变得清楚，你会遇到的问题是更糟糕的这一套。但是，如果一个文件在尾部有一个带有尾部空格的行，它似乎创建了一个主要的问题。

It's related to the core.autocrlf=true behaviour. After spending a week trawling the 'net it became clear that the problems you'll encounter are less bad with this set. However, if a file has a line with trailing whitespace on the end, it appears to create a major problem.

问题是，git认为文件有本地修改，即使它不。例如，在一个全新的克隆后，'git status'或'git diff'将立即显示任何这样的文件被修改。 'git reset --hard'做它的东西，但那些文件仍然显示为修改。 'git diff'显示的差异是删除空行，添加空行。

The problem is that git thinks the file has local modifications, even though it does not. For example, after a brand-new fresh clone, a 'git status' or 'git diff' will immediately show any such files as modified. A 'git reset --hard' does its thing, but then those files still show as modified. 'git diff' shows the differences as being "an empty line removed, an empty line added".

问题是，这阻止了git pull！

The problem is, this blocks a 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)
-
+

好吧，我想 - 有一个局部的变化。如果我把它藏起来呢？ Nope - after git stash它仍然显示此文件为本地更改。

Ok, I think - there's a local change in the way. What if I stash it? Nope - after git stash it still shows this file as locally changed.

好吧，如果我添加它？当然这仍然阻止了pull：

Ok, what if I add it? Of course this still blocks a pull:

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

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

Ok, one last try - let's just commit it and be done with it. Oh great it's conflicted on this file. But the amazing thing is, the file has no conflict markers! Unfortunately 'git pull' now complains that I'm in the middle of a conflicted merge, even though there's no conflict marked.

我发现，不要在换行之前提交带有尾部空格的文件。它只是导致git认为文件被修改时，它不是，可能是由于DOS-UNIX行结束逻辑明显破碎。

The fix, I've discovered, is to never commit a file with trailing whitespace before a newline. It just causes git to think the file is modified when it's not, probably due to the DOS-UNIX line ending logic that's obviously broken.

无论如何，我不是真的寻找答案，因为最后我只是注意了整个事情，重新登场。我真的想知道的是，当试图用Cygwin使用git时，有没有人保持他们的理智。

Anyway, I'm not really looking for an answer, because in the end I just nuked the entire thing and recloned. What I'd really like to know is how anyone maintains their sanity while trying to use git with Cygwin.

不要让我开始'git add foo / a当目录被调用FOO时，foo / b FOO / c ...

Don't get me started on 'git add foo/a foo/b FOO/c' when the directory is called "FOO"...

推荐答案

使用UNIX eol风格，我一直将 core.autocrlf 设置为false。

请参见此回答

In my experience, all my files use the UNIX eol style, and I have always set the core.autocrlf to false.
See this SO answer

自动，特别是在分布式环境（您不能保证在远程存储库上进行相同的设置）要求麻烦。

Anything which happens "automagically", especially in a distributed environment (where you cannot guarantee the same setup on remote repositories) is asking for trouble.

基本上，如果你的工具一个用于合并）设置正确，他们将处理任何空间/ eol问题。不直接Git。

Basically, if your tools (like the one used for merge) are set correctly, they will handle any space/eol issue. Not Git directly.

这篇关于git& Cygwin - 尾随空白导致“不uptodate”的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！