git & Cygwin - конечный пробел приводит к "не обновлению"

Question

Git на Windows с Cygwin таит в себе опасность. Однако есть один, который действительно начинает меня беспокоить.

Это связано с поведением core.autocrlf=true. Потратив неделю на траление в сети, стало ясно, что проблемы, с которыми вы столкнетесь, не так плохи в этом наборе. Однако, если файл имеет строку с конечным пробелом в конце, это создает серьезную проблему.

Проблема в том, что git считает, что файл имеет локальные модификации, даже если это не так. Например, после нового свежего клона в "git status" или "git diff" такие файлы будут немедленно отображаться как измененные. 'Git reset --hard' делает свое дело, но тогда эти файлы по-прежнему отображаются как измененные. 'git diff' показывает различия как "удалена пустая строка, добавлена ​​пустая строка".

Проблема в том, что это блокирует удар!

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

Не начинайте меня с 'git add foo/a foo/b FOO/c', когда каталог называется "FOO"...

Answer 1

По моему опыту, все мои файлы используют стиль UNIX eol, и я всегда устанавливал core.autocrlf ложно.
Смотрите этот так ответ

Все, что происходит " автоматически", особенно в распределенной среде (где вы не можете гарантировать такую ​​же настройку в удаленных репозиториях), вызывает проблемы.

По сути, если ваши инструменты (например, те, что используются для слияния) настроены правильно, они будут обрабатывать любые проблемы с пробелами /eol. Не Git напрямую.