Я прочитал много разных вопросов и ответов о переполнении стека, а также документацию git о том, как работает параметр core.autocrlf.
Это мое понимание из того, что я прочитал:
Unix и Mac OSX (pre-OSX использует CR) клиенты используют концы строк LF.
Клиенты Windows используют концы строк CRLF.
Когда core.autocrlf установлен на true на клиенте, репозиторий git всегда хранит файлы в формате окончания строки LF, а окончание строк в файлах на клиенте преобразуется взад и вперед по проверке/фиксации для клиентов (т.е. Windows), которые используют концы строк, отличных от LF, независимо от того, в каком формате находятся файлы окончаний строки на клиенте (это не согласуется с определением Tim Clem - см. Обновление ниже).
Вот матрица, которая пытается документировать то же самое для "ввода" и "ложных" настроек core.autocrlf с вопросительными знаками, где я не уверен в поведении преобразования конца строки.
Мои вопросы:
- Какими должны быть вопросительные знаки?
- Является ли эта матрица правильной для "знаков без вопроса"?
Я обновляю вопросительные знаки из ответов, поскольку консенсус, как представляется, формируется.
core.autocrlf value
true input false
----------------------------------------------------------
commit | convert ? ?
new | to LF (convert to LF?) (no conversion?)
commit | convert to ? no
existing | LF (convert to LF?) conversion
checkout | convert to ? no
existing | CRLF (no conversion?) conversion
Я действительно не ищу мнения о плюсах и минусах различных настроек. Я просто ищу данные, которые дают понять, как ожидать, что git будет работать с каждой из трех настроек.
-
Обновление 04/17/2012: после прочтения статьи Тима Клема, связанной JJD в комментариях, Я изменил некоторые значения в "неизвестных" значениях в приведенной выше таблице, а также изменил "checkout existing | true", чтобы преобразовать в CRLF вместо преобразования в клиент ". Вот определения, которые он дает, которые более ясны, чем все, что я видел в другом месте:
core.autocrlf = false
Это значение по умолчанию, но большинству людей предлагается изменить это немедленно. Результатом использования false является то, что git не испортит с окончанием строки в вашем файле. Вы можете проверить файлы с помощью LF или CRLF или CR, или какое-то случайное сочетание этих трех и git не волнует. Эта может затруднить чтение и слияние. Большинство людей работа в мире Unix/Linux использует это значение, потому что у них нет CRLF, и им не нужно git выполнять дополнительную работу файлы записываются в базу данных объекта или записываются в рабочий каталог.
core.autocrlf = true
Это означает, что git обработает все текстовые файлы и убедитесь, что CRLF заменяется LF при записи этого файла в базу данных объекта и превратить все LF обратно в CRLF при записи в рабочий каталог. Это рекомендуемая настройка для Windows, потому что она гарантирует, что ваш репозиторий можно использовать на других платформах, в то время как сохраняя CRLF в вашем рабочем каталоге.
core.autocrlf = input
Это означает, что git обработает все текстовые файлы и убедитесь, что CRLF заменяется LF при записи этого файла на объект база данных. Однако он не будет делать обратного. Когда вы читаете файлы вернуться из базы данных объектов и записать их в рабочий в каталоге они все равно будут иметь LF, чтобы обозначить конец строки. Эта обычно используется в Unix/Linux/OS X, чтобы предотвратить CRLF от записывается в репозиторий. Идея состоит в том, что если вы вставили код из веб-браузера и случайно получил CRLF в один из ваших файлы, git, убедитесь, что они были заменены LF, когда вы написали к базе данных объектов.
Тим статьи превосходный, единственное, что я могу думать об этом, так это то, что он предполагает, что репозиторий находится в формате LF, что не обязательно верно, особенно для проектов только для Windows.
Сравнение статьи Тима с самым высоким голосовым ответом на сегодняшний день jmlane показывает полное согласие с истинными и входными настройками и несогласие с ложными настройками.