Git в Windows с Cygwin чревато опасностями. Однако есть тот, который действительно начинает меня пугать.
Это связано с ядром .autocrlf = истинное поведение. Проведя неделю, травляя "сеть", стало ясно, что проблемы, с которыми вы столкнетесь, менее плохи с этим набором. Однако, если файл имеет строку с завершающим пробелом в конце, это создает серьезную проблему.
Проблема заключается в том, что git считает, что файл имеет локальные модификации, даже если это не так. Например, после нового нового клона статус git или 'git diff' немедленно покажет любые файлы, которые были изменены. A 'git reset --hard' делает свою вещь, но тогда эти файлы по-прежнему отображаются как измененные. 'git diff' показывает различия как "удаленная пустая строка, добавлена пустая строка".
Проблема заключается в том, что это блокирует 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 - после 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 добавлять foo/a foo/b FOO/c ', когда каталог называется "FOO"...
По моему опыту, все мои файлы используют стиль UNOL eol, и я всегда устанавливал core.autocrlf в false.
См. Этот SO ответ
Все, что происходит "автоматически", особенно в распределенной среде (где вы не можете гарантировать ту же настройку в удаленных репозиториях) запрашивает проблемы.
В принципе, если ваши инструменты (например, используемые для объединения) установлены правильно, они будут обрабатывать любую проблему пространства/эла. Не Git напрямую.