开发者

git & Cygwin - trailing whitespace causes "not uptodate" [closed]

开发者 https://www.devze.com 2022-12-09 04:38 出处:网络
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical andcannot be reasonably answered in its current form. For help clari
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center. Closed 13 years ago.

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

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.

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".

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)
-
+

Ok, I think - there's a local change in the way. What if I stash it? Nope - af开发者_JAVA技巧ter git stash it still shows this file as locally changed.

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.

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.

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.

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.

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


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.

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

0

精彩评论

暂无评论...
验证码 换一张
取 消