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

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

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

44
git line-endings

3 ответов

Я бы рекомендовал, как я сделал в этом и, чтобы установить значение false.

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

33

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

15

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

выбор по умолчанию, сделанный () git (designers), должен использовать символ * Nix style EOL (только LF), когда это возможно, так что для тот же текст контент вы получаете тот же SHA1. (вероятно, важное соображение; -)

поскольку контент / blob больше не запоминает исходный выбор EOL пользователя (помните , что он, возможно, теперь находится в каком-то удаленном репозитории), Git должен сделать некоторые догадки (на основе опции) о том, как воссоздать исходный файл пользователя (был ли это CRLF или просто LF) таким образом, что вы (и ваши инструменты) можете использовать.

обычная рекомендация заключается в том, что локально у каждого пользователя (a) преобразует в *nix LF-окончания при фиксации в blob (так что все будут видеть общие имена blob SHA1) (a/k/A правильная вещь), и (b) локально установите параметр повторного создания в свою локальную системную настройку, например *nix(LF) или Windows(CRLF) и т. д.

установите некоторые локальные стандарты для ваших пользователей и сделайте один большой "EOL/LF / CRLF & Whitespace Correction commit", и вы будете в порядке (плюс повторное обучение новых пользователей)

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

13