Окончательная рекомендация для настроек git autocrlf

Question

Я пользуюсь Windows, Mac OS X и linux ежедневно. Я использую git во всех этих средах, извлекая из репозиториев, которые используют люди с разными вариантами окончания строк.

Существуют ли конкретные рекомендации по настройке core.autocrlf в моей ситуации?

Answer 1

Я бы порекомендовал, как я делал в этом ТАКОМ вопросе , установить его в значение false.

Если вы можете избежать изменения любого eol (с помощью вашего редактора), то было бы лучше отодвинуть вашу работу с этими eol без изменений (т. Е. «Как вы их нашли»).

Answer 2

Одна проблема, которая часто не упоминается в этих обсуждениях: если вы разрабатываете сценарии оболочки для windows (скажем, в cygwin) и фиксируете их с помощью CRLF (autocrlf = false), они будут падать в * nix-окнах с бесполезными сообщениями об ошибках. (Могут быть аналогичные случаи с другими языками сценариев.) После того, как вы почесали голову в течение получаса, вы вспомните и затем dos2unix маленьких негодяев. Если вы работаете в смешанной среде (скажем, развертывание из Windows на сервере Linux) и вам абсолютно необходимо установить для autocrlf значение false, то УБЕДИТЕСЬ, что во всех ваших редакторах Windows используется конец строки unix (lf). В противном случае установите autocrlf для ввода (и молитесь). Большинство программ 21-го века для Windows удобны без ранних принтеров CR 1980-х годов, поэтому неплохо было бы в любом случае установить в LF (unix) окончания строк.

Answer 3

GIT НЕ будет иметь общих SHA1 для двух текстовых файлов с идентичным текстом, но различными механизмами конца строки (EOL) внутри двоичного представления. Содержимое хранится в виде большого двоичного объекта, который повторно используется , если другая идентичная копия удаляется в хранилище (экономия места!)

По умолчанию, выбранный GIT (дизайнерами), по умолчанию используется символ EOL в стиле * nix (только LF), чтобы для того же текста content вы получали тот же 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 и исправление пробелов', и у вас все будет хорошо (плюс переподготовка новых пользователей)

Вы также можете убедиться, что вы (каждый пользователь) используете общую настройку пробелов, чтобы вкладки v пробелы и конечные пробелы не доставляли больше diff неудобств!