Я прочитал много разных вопросов и ответов по переполнению стека, а также git документацию о том, как работает параметр core.autocrlf .
Это мое понимание того, что я прочитал:
Клиенты Unix и Mac OSX (pre-OSX использует CR) используют LF-окончания строк.
Клиенты Windows используют окончания строки CRLF.
Когда для core.autocrlf на клиенте установлено значение true, репозиторий git всегда сохраняет файлы в формате окончания строки LF, а окончания строк в файлах на клиенте конвертируются туда-обратно при извлечении / фиксации для клиентов (т. Е. Windows), которые используют не -LF окончания строк, независимо от формата файлов окончаний строк на клиенте (это не согласуется с определением Тима Клема - см. Обновление ниже).
Вот матрица, которая пытается документировать то же самое для параметров «input» и «false» в файле core.autocrlf с вопросительными знаками, где я не уверен в поведении преобразования конца строки.
Мои вопросы:
- Какими должны быть знаки вопроса?
- Правильна ли эта матрица для «не вопросительных знаков»?
Я обновлю вопросительные знаки из ответов, поскольку консенсус, кажется, сформирован.
значение core.autocrlf верный ввод ложный -------------------------------------------------- -------- совершать | перерабатывать ? ? новый | в LF (преобразовать в LF?) (без преобразования?) совершать | Перевести в ? нет существующий | LF (конвертировать в LF?) Конвертация оформить заказ | Перевести в ? нет существующий | CRLF (без конвертации?) Конвертация
Я на самом деле не ищу мнения о плюсах и минусах различных настроек. Я просто ищу данные, которые проясняют, как ожидать, что git будет работать с каждой из трех настроек.
-
Обновление 17.04.2012 : После прочтения статьи Тима Клема, связанной JJD в комментариях, я изменил некоторые значения в «неизвестных» значениях в приведенной выше таблице, а также изменил «checkout существующие | 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 = вход
Это означает, что Git обработает все текстовые файлы и убедится, что CRLF заменяется на LF при записи этого файла в объектную базу данных. Это не будет, однако, делать обратное. Когда вы читаете файлы обратно из базы данных объектов и записываете их в рабочий каталог, они все равно будут иметь LF для обозначения конца строки. Этот параметр обычно используется в Unix / Linux / OS X для предотвращения записи CRLF в репозиторий. Идея заключалась в том, что если вы вставили код из веб-браузера и случайно поместили CRLF в один из ваших файлов, Git удостоверится, что они будут заменены на LF при записи в базу данных объектов.
Статья Тима отличная, единственное, о чем я могу подумать, что она отсутствует, это то, что он предполагает, что репозиторий имеет формат LF, что не всегда верно, особенно для проектов только для Windows.
Сравнение статьи Тима с ответом jmlane, получившим наибольшее количество голосов на сегодняшний день, показывает идеальное согласие с истинными и исходными настройками и несогласие с ложными настройками.
источник
autocrlf
ложь кажется намного проще;) stackoverflow.com/questions/2333424/…Ответы:
Лучшее объяснение того, как это
core.autocrlf
работает, можно найти на справочной странице gitattributes в разделеtext
атрибутов.Вот как
core.autocrlf
работает в настоящее время (или, по крайней мере, начиная с v1.7.2, насколько я знаю):core.autocrlf = true
LF
символы, нормализуютсяCRLF
в вашем рабочем дереве; файлы, которые содержатсяCRLF
в хранилище, не будут затронутыLF
символы в репозитории, нормализуются отCRLF
до,LF
когда фиксируются обратно в репозиторий. Файлы, содержащиесяCRLF
в хранилище, будут сохранены без изменений.core.autocrlf = input
CRLF
символами нормализуются,LF
когда они возвращаются в хранилище.core.autocrlf = false
core.eol
диктует символы EOL в текстовых файлах вашего рабочего дерева.core.eol = native
по умолчанию это означает, что Windows EOL есть,CRLF
а * nix EOLLF
в рабочих деревьях.gitattributes
Настройки репозитория определяют нормализацию символов EOL для коммитов в репозиторий (по умолчанию нормализация дляLF
символов).Я только недавно исследовал эту проблему, и я также считаю, что ситуация очень запутанная.
core.eol
Установка определенно помогла уточнить , как символы EOL обрабатывается мерзавцем.источник
core.autocrlf = false
если у меня нетgitattributes
файла, значит ли это, что нормализации не будет? Или это означает, что будет использоваться нормализация по умолчанию?.gitattributes
файл не должен иметь приоритет надcore.autocrlf
настройкой?Проблема EOL в проектах на смешанных платформах давно делает мою жизнь несчастной. Проблемы обычно возникают , когда уже есть файлы с различным и смешанным EOL в уже в репо. Это означает, что:
CRLF
иLF
в одном и том же файле.Как это происходит, здесь не проблема, но это случается.
Я провел несколько тестов конвертации в Windows для различных режимов и их комбинаций.
Вот что я получил в слегка измененной таблице:
Как вы можете видеть, есть 2 случая, когда преобразование происходит при фиксации (3 левых столбца). В остальных случаях файлы сохраняются как есть.
При оформлении заказа (3 правых столбца) конверсия происходит только в одном случае, когда:
core.autocrlf
этоtrue
иLF
EOL.Самое удивительное для меня, и я подозреваю, что причина многих проблем с EOL заключается в том, что нет конфигурации, в которой смешанный EOL, такой как
CRLF
+,LF
нормализуется.Также обратите внимание, что «старые» Mac только из EOL
CR
никогда не конвертируются.Это означает, что если плохо написанный сценарий преобразования EOL пытается преобразовать смешанный конечный файл с помощью
CRLF
s +LF
s, просто преобразовавLF
s вCRLF
s, то он оставит файл в смешанном режиме с «одинокими»,CR
куда бы он ниCRLF
был преобразованCRCRLF
.Git не будет ничего конвертировать, даже в
true
режиме, и EOL хаос продолжается. Это на самом деле произошло со мной и испортило мои файлы очень сильно, поскольку некоторые редакторы и компиляторы (например, VS2010) не любят Mac EOL.Я предполагаю, что единственный способ действительно решить эти проблемы - это иногда нормализовать весь репозиторий, проверяя все файлы в режиме
input
илиfalse
режиме, выполняя надлежащую нормализацию и повторно фиксируя измененные файлы (если таковые имеются). На Windows, предположительно, возобновить работу сcore.autocrlf true
.источник
core.autocrlf true
. Я лично считаю, чтоinput
следует использовать всегда.Ситуация "Eol Conversion" скоро изменится с выходом Git 1.7.2 :
Новый параметр конфигурации
core.eol
добавляется / развивается :Другие эволюции рассматриваются :
git 2.8 (март 2016 г.) улучшает способ
core.autocrlf
влияния на eol:См. Коммит 817a0c7 (23 февраля 2016 года), коммит 6e336a5 , коммит df747b8 , коммит df747b8 (10 фев 2016), коммит df747b8 , совершают df747b8 (10 Feb 2016), а также совершать 4b4024f , совершают bb211b4 , совершают 92cce13 , совершают 320d39c , совершают 4b4024f , коммит bb211b4 , коммит 92cce13 , коммит 320d39c (05 февраля 2016 г.) от Torsten Bögershausen (
tboegi
) .(Слиты Junio C Hamano -
gitster
- в коммите c6b94eb, 26 Feb 2016)Как Торек добавляет в комментариях :
Подробнее об этом см. «В чем разница между autocrlf и eol ».
источник
core.eol
речь идет об «автоматическом изменении» только того, что вы явно объявили в.gitattributes
файле. Это отличается от того,core.autocrlf
который применяется к любому файлу в репо. Это декларативный процесс.git add
а не воgit commit
время. (Обратите внимание , чтоgit commit -a
или--only
или--include
делать добавление файлов в индекс в то время, хотя.) Для чего это стоит, вы и я , и Линус Торвальдс все ненавидите идею о VCS когда - либо изменений , что совершается. Но все эти пользователи Windows , ... :-)core.autocrlf
значение не зависит от типа ОС, но для Windows значение по умолчанию -true
и для Linux -input
. Я исследовал 3 возможных значения для случаев фиксации и извлечения, и вот таблица:источник
CR
одним никогда не трогаются.false
никогда не касается концов строк.true
всегда совершает какLF
и проверяет какCRLF
. Иinput
всегда фиксирует какLF
и проверяет как есть.Вот мое понимание этого до сих пор, на случай, если это кому-то поможет.
core.autocrlf=true
иcore.safecrlf = true
У вас есть репозиторий, в котором все окончания строк одинаковы , но вы работаете на разных платформах. Git позаботится о том, чтобы окончания строк были преобразованы в значения по умолчанию для вашей платформы. Почему это важно? Допустим, вы создаете новый файл. Текстовый редактор на вашей платформе будет использовать окончания строк по умолчанию. Когда вы включаете его, если у вас не установлено значение true для core.autocrlf, вы вводите несоответствие конца строки для кого-то на платформе, которая по умолчанию имеет другое окончание строки. Я тоже всегда устанавливаю safecrlf, потому что хотел бы знать, что операция crlf обратима. С этими двумя настройками git изменяет ваши файлы, но проверяет, что изменения обратимы .
core.autocrlf=false
У вас есть репозиторий, в котором уже зарегистрированы смешанные окончания строк, и исправление неправильных окончаний строк может привести к поломке. В этом случае лучше не указывать git преобразовывать окончания строк, потому что тогда это усугубит проблему, для решения которой оно было разработано - облегчить чтение различий и объединить менее болезненные. С этим параметром git не изменяет ваши файлы .
core.autocrlf=input
Я не использую это, потому что причина этого состоит в том, чтобы покрыть случай использования, когда вы создали файл с окончаниями строк CRLF на платформе, по умолчанию заканчивающимися на концах строк LF. Вместо этого я предпочитаю, чтобы мой текстовый редактор всегда сохранял новые файлы со значениями конца строки на платформе.
источник
Нет, ответ @jmlane неправильный.
Для
Checkin (git add, git commit)
:text
свойство имеет значениеSet, Set value to 'auto'
, преобразование происходит, если файл был зафиксирован с помощью CRLF.text
свойствоUnset
: ничего не происходит, enen дляCheckout
text
свойство естьUnspecified
, конвертация зависит отcore.autocrlf
autocrlf = input or autocrlf = true
преобразование происходит только тогда, когда файл в хранилище имеет значение «LF», если это был «CRLF», ничего не произойдет.autocrlf = false
ничего не происходитДля
Checkout
:text
свойство естьUnset
: ничего не происходит.text
свойствоSet, Set value to 'auto
: это зависит от тогоcore.autocrlf
,core.eol
.core.eol
text
свойствоUnspecified
, это зависит отcore.autocrlf
.2.1
2.2
text
свойствоUnspecified
Поведение по умолчанию
Таким образом, поведение по умолчанию является
text
свойствомUnspecified
иcore.autocrlf = false
:Выводы
text
свойство установлено, поведение при регистрации зависит от самого себя, а не от autocrlfисточник
Провел несколько тестов как на Linux, так и на Windows. Я использую тестовый файл, содержащий строки, оканчивающиеся на LF, а также строки, оканчивающиеся на CRLF.
Файл зафиксирован, удален и затем извлечен. Значение core.autocrlf устанавливается перед фиксацией, а также перед извлечением. Результат ниже.
источник