Как преобразование окончания строки работает с git core.autocrlf между разными операционными системами

Я прочитал много разных вопросов и ответов о переполнении стека, а также документацию git о том, как core.autocrlf работает.

Это мое понимание из того, что я прочитал:

Клиенты Unix и Mac OSX (до OSX используют CR) используют окончания строк LF.
Клиенты Windows используют окончания строк CRLF.

Когда для core.autocrlf на клиенте задано значение true, в репозитории git файлы всегда хранятся в формате окончания строки LF, а окончания строк в файлах на клиенте преобразуются туда и обратно при извлечении / фиксации для клиентов (например, Windows). которые используют окончания строк, отличные от LF, независимо от того, в каком формате файлы окончаний строк находятся на клиенте (это не согласуется с определением Тима Клема - см. обновление ниже).

Вот матрица, которая пытается задокументировать то же самое для настроек «input» и «false» в core.autocrlf с вопросительными знаками, когда я не уверен в поведении преобразования конца строки.

Мои вопросы:

1. Какими должны быть вопросительные знаки?
2. Верна ли эта матрица для «не вопросительных знаков»?

Я обновлю вопросительные знаки из ответов, поскольку консенсус кажется быть сформированным.

                       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 будет работать с каждой из трех настроек.

-

Обновление от 17.04.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 в вашем рабочем каталоге.

ядро.autocrlf = input

Это означает, что Git обработает все текстовые файлы и обеспечит замену CRLF на LF при записи этого файла в базу данных объекта . Однако обратного не произойдет. Когда вы считываете файлы обратно из объектной базы данных и записываете их в рабочий каталог , они все еще будут иметь LF для обозначения конца строки. Этот параметр обычно используется в Unix / Linux / OS X для предотвращения записи CRLF в репозиторий. Идея состоит в том, что если вы вставили код из веб-браузера и случайно получили CRLF в один из ваших файлов , Git позаботится о том, чтобы они были заменены на LF, когда вы написали в база данных объектов.

Статья Тима превосходна, единственное, о чем я думаю, чего не хватает, так это того, что он предполагает, что репозиторий находится в формате LF, что не всегда верно, особенно для проектов только для Windows.

Сравнение статьи Тима с ответом jmlane, получившим наибольшее количество голосов на сегодняшний день, показывает полное согласие по истинным и входным настройкам и несогласие с ложными настройками.