Я использую Windows, Mac OS X и Linux на ежедневной основе. Я использую git во всех этих средах, вытягивая из репозиториев, которые используются людьми с различными вариантами окончаний строк.
Есть ли окончательная рекомендация по установке core.autocrlf в моей ситуации?
Я бы порекомендовал, как и в этом SO вопрос, чтобы установить его в false.
Если вы можете избежать изменения любого eol (с помощью вашего редактора), тогда было бы лучше отодвинуть вашу работу с этими eol без изменений (т.е. "как вы их нашли" ).
Одна проблема, которая часто не упоминается в этих обсуждениях: если вы разрабатываете сценарии оболочки на окнах (скажем, в cygwin) и фиксируете их с помощью CRLF (autocrlf = false), они будут разбиваться на * nix-боксы с бесполезными сообщениями об ошибках. (Подобные случаи могут встречаться и с другими языками сценариев.) Почесывая голову на полчаса, вы будете помнить, а затем dos2unix маленьких негодяев. Если вы работаете в смешанной среде (скажем, развертывание с Windows на сервер Linux), и вы абсолютно хотите установить autocrlf в false, тогда УБЕДИТЕСЬ, что все ваши редакторы окон используют окончание строк unix (lf). В противном случае установите autocrlf для ввода (и молитвы). Большинство программ Windows 21st Century удобны без линейных принтеров CR 1980 года, поэтому в любом случае рекомендуется установить линейные окончания для LF (unix).
GIT не будет иметь общего SHA1 для двух текстовых файлов с идентичным текстом, но с различными механизмами конца строки (EOL) внутри двоичного представления. Содержимое сохраняется как blob, который используется повторно, если другая копия помещается в репозиторий (сохранение пространства!)
Выбор по умолчанию, сделанный (w) GIT (дизайнерами), заключается в использовании символа EOL стиля EIX (только LF), когда это возможно, так что для одного и того же текстового содержимого вы получите тот же SHA1. (вероятно, важное соображение;)
Поскольку контент /blob больше не запоминает исходный выбор EOL пользователя (помните, возможно, сейчас в каком-то удаленном репозитории), GIT должен сделать некоторые догадки (на основе опций) о том, как воссоздать исходный файл пользователя (было ли это CRLF или это просто LF) таким образом, чтобы вы (и ваши инструменты) могли использовать.
Нормальная рекомендация заключается в том, что локально каждый пользователь (а) преобразуется в концы * nix LF при компиляции в blob (так что все будут видеть общие имена blob SHA1) (a/k/a the Right Thing) и (b) локально установите параметр повторного создания на локальную систему, например * nix (LF) или Windows (CRLF) и т.д.
Задайте некоторые локальные стандарты для своих пользователей и получите один большой "EOL/LF/CRLF" и "Коррекция свободной пробелы", и вы будете в порядке (плюс обучение переподготовке новых пользователей)
Вы также можете убедиться, что вы (каждый пользователь) используете общую настройку регулировки белого пространства, так что вкладки v пробелов и конечные пробелы не вызывают больше diff неудобств!