Окончательная рекомендация для настроек git autocrlf
Я использую Windows, Mac OS X и Linux на ежедневной основе. Я использую git во всех этих средах, извлекая из репозиториев, которые используются людьми с разными вариантами окончания строк.
Есть ли точные рекомендации по настройке core.autocrlf в моей ситуации?
3 ответа
Я бы порекомендовал, как я сделал в этом вопросе, установить его в ложь.
Если вы можете избежать изменения любого eol (с помощью вашего редактора), то было бы лучше отодвинуть вашу работу с этими eol без изменений (то есть "как вы их нашли").
Одна проблема, которая часто не упоминается в этих обсуждениях: если вы разрабатываете сценарии оболочки в Windows (скажем, в cygwin) и фиксируете их с помощью CRLF (autocrlf=false), они будут аварийно завершаться на полях *nix с бесполезными сообщениями об ошибках. (Могут быть аналогичные случаи с другими языками сценариев.) После того, как вы почесали голову в течение получаса, вы вспомните и затем dos2unix маленьких негодяев. Если вы работаете в смешанной среде (скажем, развертывание из Windows на сервере Linux) и вы абсолютно хотите установить для autocrlf значение false, убедитесь в том, что все ваши редакторы Windows используют концы строк unix (lf). В противном случае установите autocrlf для ввода (и молитесь). Большинство программ Windows 21-го века удобны без ранних принтеров CR 1980-х годов, так что в любом случае неплохо бы установить конечные значения LF (unix).
GIT НЕ будет иметь общих SHA1 для двух текстовых файлов с одинаковым текстом, но с разными механизмами конца строки (EOL) внутри двоичного представления. Содержимое хранится в виде большого двоичного объекта, который используется повторно, если в хранилище помещается другая идентичная копия (экономия места!)
GIT (разработчики) по умолчанию выбирают использование символа EOL в стиле * nix (только LF), чтобы для одного и того же текстового содержимого вы получали один и тот же SHA1. (вероятно, важное соображение;-)
Поскольку content/blob больше не запоминает исходный выбор EOL пользователя (помните, что он, возможно, теперь находится в некотором удаленном хранилище), Git должен сделать некоторые предположения (основанные на опциях) о том, как воссоздать исходный файл пользователя (был ли это CRLF или просто LF) таким образом, что вы (и ваши инструменты) можете использовать.
Обычная рекомендация заключается в том, что локально каждый пользователь (a) преобразует в *nix LF окончания при фиксации в BLOB (так что все будут видеть общие имена BLA SHA1) (a/k/a Right Thing), и (b) локально устанавливает возможность воссоздания с настройкой их локальной системы, например *nix(LF) или Windows(CRLF) и т. д.
Установите некоторые локальные стандарты для своих пользователей и получите один большой коммит EOL/LF/CRLF & Whitespace Correction ', и все будет в порядке (плюс переподготовка новых пользователей)
Вы также можете убедиться, что вы (каждый пользователь) используете общую настройку пробелов, чтобы вкладки v пробелы и конечные пробелы не вызывали больше diff Неудобства!