Ответ 1
предупреждение: LF будет заменен на CRLF.
В зависимости от того, какой редактор вы используете, текстовый файл с LF не обязательно будет сохранен с CRLF: последние редакторы могут сохранить стиль eol. Но эта настройка git config настаивает на изменении этих...
Просто убедитесь, что (как я рекомендую здесь):
git config --global core.autocrlf false
Таким образом, вы избегаете любых автоматических преобразований и можете указать их с .gitattributes файла core.eol директив core.eol.
Windows Git "LF будет заменен на CRLF"
Это предупреждение хвост назад?
Нет: вы находитесь в Windows, и на странице справки git config не упоминается
Используйте этот параметр, если вы хотите, чтобы в вашем рабочем каталоге были окончания строк
CRLFдаже если в репозитории нет нормализованных окончаний строк.
Как описано в " git, заменяющем LF на CRLF ", это должно происходить только при извлечении (а не при фиксации), с core.autocrlf=true.
repo
/ \
crlf->lf lf->crlf
/ \
Как упоминалось в ответе XiaoPeng, это предупреждение аналогично:
предупреждение: (Если вы проверите его или клонируете в другую папку с текущей конфигурацией
core.autocrlf,) LF будет заменен на CRLF
Файл будет иметь исходные окончания строк в вашем (текущем) рабочем каталоге.
Как упомянуто в git-for-windows/git выпуск 1242:
Я все еще чувствую, что это сообщение сбивает с толку, сообщение может быть расширено, чтобы включить лучшее объяснение проблемы, например: "LF будет заменен на CRLF в
file.jsonпосле удаления файла и проверки его снова".
Примечание: Git 2.19 (сентябрь 2018), когда используется core.autocrlf, core.autocrlf "LF будет заменено CRLF" теперь подавляется.
Как справедливо комментирует Куэйлар, если преобразование происходит при коммите, то только в LF.
Это конкретное предупреждение " LF will be replaced by CRLF " приходит из convert.С# 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#crlf_to_git(), сам convert.c#convert_to_git() convert.c#renormalize_buffer().
И этот последний renormalize_buffer() вызывается только с помощью merge-recursive.c#blob_unchanged().
Поэтому я подозреваю, что это преобразование происходит в git commit только если указанный коммит является частью процесса слияния.
Примечание: в Git 2.17 (Q2 2018) очистка кода добавляет некоторые пояснения.
См. Коммит 8462ff4 (13 января 2018 г.) Торстена Бёгерсхаузена (tboegi).
(Объединено Джунио К Хамано - 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 переписывать, чтобы autocrlf предупреждение, несмотря на установку safecrlf=false,
См. Коммит 6cb0912 (04 июня 2018 г.) Энтони Соттиля (asottile).
(Объединено Junio C Hamano - gitster - в коммите 8063ff9, 28 июня 2018 г.)
