предупреждение: LF будет заменен на CRLF.
В зависимости от редактора, который вы используете, текстовый файл с LF не обязательно сохранять с CRLF: последние редакторы могут сохранять стиль eol. Но этот параметр конфигурации git настаивает на изменении этих ...
Просто убедитесь, что (как я рекомендую здесь ):
git config --global core.autocrlf false
Таким образом, вы избегаете каких-либо автоматических преобразований и по-прежнему можете указывать их через .gitattributesфайл и core.eolдирективы .
windows git "LF будет заменен на CRLF"
Это предупреждение "хвост" назад?
Нет: вы используете Windows, и на git configстранице справки упоминается
Используйте этот параметр, если вы хотите, чтобы CRLFв рабочем каталоге были окончания строк, даже если в репозитории нет нормализованных окончаний строк.
Как описано в разделе « git, заменяющий LF на CRLF », это должно происходить только при проверке (не при фиксации) с core.autocrlf=true.
repo
/ \
crlf->lf lf->crlf
/ \
Как уже упоминалось в Сяопина «s ответ , что предупреждение является такой же , как:
предупреждение: (Если вы отметите его / или клонируете в другую папку с вашей текущей core.autocrlfконфигурацией) LF будет заменен на CRLF
Файл будет иметь свои исходные окончания строки в вашем (текущем) рабочем каталоге.
Как упоминалось в git-for-windows/gitвыпуске 1242 :
Мне все еще кажется, что это сообщение сбивает с толку, сообщение можно расширить, включив в него более подробное объяснение проблемы, например: «LF будет заменен на CRLF в file.jsonпосле удаления файла и повторной проверки».
Примечание: Git 2,19 (сентябрь 2018), при использовании core.autocrlf, фиктивная «LF будет заменен CRLF» предупреждение теперь подавляется .
Как справедливо комментирует Квайлар , если при фиксации происходит преобразование, то только в.LF
Это конкретное предупреждение " LF will be replaced by CRLF" исходит от convert.c # check_safe_crlf () :
if (checksafe == SAFE_CRLF_WARN)
warning("LF will be replaced by CRLF in %s.
The file will have its original line endings
in your working directory.", path);
else /* i.e. SAFE_CRLF_FAIL */
die("LF would be replaced by CRLF in %s", path);
Он вызывается convert.c#crlf_to_git(), сам вызывается convert.c#convert_to_git(), сам вызывается convert.c#renormalize_buffer().
И последний renormalize_buffer()только вызывается merge-recursive.c#blob_unchanged().
Поэтому я подозреваю, что это преобразование происходит git commitтолько в том случае, если указанная фиксация является частью процесса слияния.
Примечание. В Git 2.17 (второй квартал 2018 г.) очистка кода добавляет некоторые пояснения.
См. Коммит 8462ff4 (13 января 2018 г.) Торстена Бёгерсхаузена ( tboegi) .
(Объединено Junio C Hamano - gitster- в коммите 9bc89b1 , 13 февраля 2018 г.)
convert_to_git (): safe_crlf / checkafe становится int conv_flags
При вызове convert_to_git(), то checksafeпараметр определяется , что должно произойти , если преобразование EOL ( CRLF --> LF --> CRLF) не в обе стороны чисто.
Кроме того, он также определяет, следует ли перенормировать окончания строк ( CRLF --> LF) или оставить их как есть.
checkafe - это safe_crlfперечисление со следующими значениями:
SAFE_CRLF_FALSE: do nothing in case of EOL roundtrip errors
SAFE_CRLF_FAIL: die in case of EOL roundtrip errors
SAFE_CRLF_WARN: print a warning in case of EOL roundtrip errors
SAFE_CRLF_RENORMALIZE: change CRLF to LF
SAFE_CRLF_KEEP_CRLF: keep all line endings as they are
Обратите внимание, что регрессия, представленная в 8462ff4 (« convert_to_git():
safe_crlf/checksafeстановится int conv_flags», 2018-01-13, Git 2.17.0) еще в цикле Git 2.17, вызвала autocrlfперезапись с выдачей предупреждающего сообщения,
несмотря на установкуsafecrlf=false .
См. Commit 6cb0912 (4 июня 2018 г.) Энтони Соттиля ( asottile) .
(Объединено Junio C Hamano - gitster- в фиксации 8063ff9 , 28 июня 2018 г.)