Git заменяет LF на CRLF

Question

Git заменяет LF на CRLF

Запуск git на машине с Windows XP, используя bash. Я экспортировал свой проект из SVN, а затем клонировал пустой репозиторий.

Затем я вставил экспорт в пустой каталог репозиториев и сделал:

git add -A

Затем я получил список сообщений, говорящих:

LF будет заменен на CRLF

Каковы последствия этого преобразования? Это решение.NET в Visual Studio.

1237

git

Источник

user68183 27 дек '09 в 23:21

26 ответов

Другие вопросы по тегам git

user237105 18 дек '13 в 08:30 2013-12-18 08:30 · Answer 1 · 2013-12-18 08:30

Эти сообщения из-за неправильного значения по умолчанию core.autocrlf на винде.

Концепция чего-либо autocrlf прозрачно обрабатывать преобразования концов строк. И это делает!

Плохая новость: значение необходимо настроить вручную.
Хорошая новость: делать это нужно ОДИН раз за установку git (также возможна настройка каждого проекта).

Как autocrlf работает:

core.autocrlf=true:      core.autocrlf=input:     core.autocrlf=false:

        repo                     repo                     repo
      ^      V                 ^      V                 ^      V
     /        \               /        \               /        \
crlf->lf    lf->crl      crlf->lf       \             /          \      
   /            \           /            \           /            \

Вот crlf = маркер конца строки в стиле win, lf = Unix-стиль (и Mac OSX).

(Предварительно OSX cr не влияет ни на один из трех вариантов выше)

Когда появляется это предупреждение (под Windows)

- autocrlf знак равно true если у вас есть Unix-стиль lf в одном из ваших файлов (= редко),
- autocrlf знак равно input если у вас есть стиль победы crlf в одном из ваших файлов (= почти ВСЕГДА),
- autocrlf знак равно false - НИКОГДА!

Что означает это предупреждение

Предупреждение " LF будет заменено CRLF " говорит, что вы (имея autocrlf знак равно true) потеряет LF в стиле Unix после цикла подтверждения (он будет заменен CRLF в стиле Windows). Git не ожидает, что вы будете использовать LF в стиле Unix под Windows.

Предупреждение " CRLF будет заменен LF " говорит, что вы (имея autocrlf знак равно input) потеряет ваш CRLF в стиле Windows после цикла подтверждения (он будет заменен LF в стиле Unix). Не использовать input под окнами.

Еще один способ показать, как autocrlf работает

1) true:             x -> LF -> CRLF
2) input:            x -> LF -> LF
3) false:            x -> x -> x

где x - это CRLF (в стиле Windows) или LF (в стиле Unix), а стрелки обозначают

file to commit -> repository -> checked out file

Как исправить

Значение по умолчанию для core.autocrlf выбирается во время установки git и сохраняется в общесистемном gitconfig (%ProgramFiles(x86)%\git\etc\gitconfig). Также есть (каскадирование в следующем порядке):

- "глобальный" (для пользователя) gitconfig, расположенный по адресу ~/.gitconfig, еще один
- "глобальный" (для пользователя) gitconfig в $XDG_CONFIG_HOME/git/config или же $HOME/.config/git/config а также
- "local" (per-repo) gitconfig в .git/config в рабочем реж.

Итак, напишите git config core.autocrlf в рабочем каталоге, чтобы проверить текущее используемое значение и

- добавлять autocrlf=false общесистемное решение gitconfig # для системы
- git config --global core.autocrlf false # решение на пользователя
- git config --local core.autocrlf false # на проектное решение

Предупреждения
- git config настройки могут быть изменены gitattributes Настройки.
- crlf -> lf преобразование происходит только при добавлении новых файлов, crlf файлы, уже существующие в репо, не затрагиваются.

Мораль (для Windows):
- использовать core.autocrlf знак равно true если вы планируете использовать этот проект также под Unix (и не желаете настраивать ваш редактор /IDE для использования концов строк Unix),
- использовать core.autocrlf знак равно false если вы планируете использовать этот проект только под Windows (или вы настроили свой редактор /IDE для использования концов строк Unix),
- никогда не используйте core.autocrlf знак равно input если у вас нет веских причин (например, если вы используете утилиты Unix под Windows или если у вас возникают проблемы с makefiles),

PS Что выбрать при установке git для Windows?
Если вы не собираетесь использовать какой-либо из ваших проектов под Unix, не соглашайтесь с первым вариантом по умолчанию. Выберите третий (Оформить заказ как есть, зафиксировать как есть). Вы не увидите это сообщение. Когда-либо.

PPS Мои личные предпочтения - это настройка редактора /IDE для использования окончаний в стиле Unix и настройка core.autocrlf в false,

user46926 28 дек '09 в 04:37 2009-12-28 04:37 · Answer 2 · 2009-12-28 04:37

У Git есть три способа обработки концов строк:

$ git config core.autocrlf
# that command will print "true" or "false" or "input"

Вы можете установить используемый режим, добавив дополнительный параметр true или же false на приведенную выше командную строку.

Если core.autocrlf установлено в true, это означает, что каждый раз, когда вы добавляете в репозиторий git файл, который git считает текстовым, он преобразует все окончания строки CRLF в просто LF, прежде чем сохранить его в коммите. Всякий раз, когда вам git checkout Что-то, все текстовые файлы автоматически будут иметь свои LF-окончания, преобразованные в CRLF-окончания. Это позволяет разрабатывать проект на разных платформах, в которых используются разные стили окончания строки, при этом коммиты не очень шумные, поскольку каждый редактор изменяет стиль окончания строки, поскольку стиль окончания строки всегда соответствует LF.

Побочный эффект этого удобного преобразования, и это то, о чем вы видите предупреждение, заключается в том, что если у созданного вами текстового файла изначально были окончания LF вместо CRLF, он будет сохранен с LF как обычно, но при проверке позже это будет иметь окончания CRLF. Для обычных текстовых файлов это обычно просто отлично. В данном случае это предупреждение "для вашей информации", но в случае, если git неправильно оценивает бинарный файл как текстовый файл, это важное предупреждение, потому что тогда git повредит ваш бинарный файл.

Если core.autocrlf имеет значение false, преобразование конца строки никогда не выполняется, поэтому текстовые файлы проверяются как есть. Обычно это работает нормально, если все ваши разработчики работают на Linux или на Windows. Но по моему опыту я все еще склонен получать текстовые файлы со смешанными окончаниями строк, которые в конечном итоге вызывают проблемы.

Мое личное предпочтение - оставить настройку включенной, как разработчик Windows.

См. http://kernel.org/pub/software/scm/git/docs/git-config.html для получения обновленной информации, включающей значение "input".

user2630328 27 апр '15 в 06:33 2015-04-27 06:33 · Answer 3 · 2015-04-27 06:33

Если вы уже проверили код, файлы уже проиндексированы. После изменения настроек git вы должны обновить индексы

git rm --cached -r .

и переписать git index с помощью

git reset --hard

https://help.github.com/articles/dealing-with-line-endings/

351

Источник

user2630328 27 апр '15 в 06:33

user1117068 21 мар '14 в 04:34 2014-03-21 04:34 · Answer 4 · 2014-03-21 04:34

git config core.autocrlf false

95

Источник

user1117068 21 мар '14 в 04:34

user262456 01 май '11 в 23:50 2011-05-01 23:50 · Answer 5 · 2011-05-01 23:50

Unix2dos и dos2unix доступны в Windows с помощью gitbash. Вы можете использовать следующую команду для выполнения преобразования UNIX(LF) -> DOS(CRLF). Следовательно, вы не получите предупреждение.

unix2dos filename

или же

dos2unix -D filename

Но не запускайте эту команду для любого существующего CRLF-файла, тогда вы будете получать пустые символы новой строки каждую вторую строку.

dos2unix -D filename не будет работать с каждой операционной системой. Пожалуйста, проверьте эту ссылку на совместимость.

Если по какой-то причине вам нужно заставить команду, то используйте --force, Если он говорит недействительным, используйте -f,

user4377192 30 июл '16 в 19:32 2016-07-30 19:32 · Answer 6 · 2016-07-30 19:32

Статья GitHub об окончаниях строк обычно упоминается при обсуждении этой темы.

Мой личный опыт использования часто рекомендуемых core.autocrlf Настройки конфига были очень смешанными.

Я использую Windows с Cygwin, работая с проектами Windows и UNIX в разное время. Даже мои проекты Windows иногда используют bash сценарии оболочки, которые требуют окончания строки UNIX (LF).

Использование GitHub рекомендуется core.autocrlf настройки для Windows, если я извлекаю проект UNIX (который отлично работает на Cygwin - или, возможно, я участвую в проекте, который я использую на своем сервере Linux), текстовые файлы извлекаются с окончаниями строк Windows (CRLF), создавая проблемы.

В основном, для смешанной среды, как у меня, настройка глобального core.autocrlf к любому из вариантов не подойдет в некоторых случаях. Эта опция может быть установлена в локальном (репозитории) git config, но даже этого будет недостаточно для проекта, который содержит как Windows, так и UNIX-компоненты (например, у меня есть проект Windows с некоторыми bash служебные скрипты).

Лучший выбор, который я нашел, - это создание файлов .gitattributes для каждого репозитория. Статья GitHub упоминает об этом.
Пример из этой статьи:

# Set the default behavior, in case people don't have core.autocrlf set.
* text=auto

# Explicitly declare text files you want to always be normalized and converted
# to native line endings on checkout.
*.c text
*.h text

# Declare files that will always have CRLF line endings on checkout.
*.sln text eol=crlf

# Denote all files that are truly binary and should not be modified.
*.png binary
*.jpg binary

В одном из репозиториев моего проекта:

* text=auto

*.txt         text eol=lf
*.xml         text eol=lf
*.json        text eol=lf
*.properties  text eol=lf
*.conf        text eol=lf

*.awk  text eol=lf
*.sed  text eol=lf
*.sh   text eol=lf

*.png  binary
*.jpg  binary

*.p12  binary

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

user59947 19 июл '14 в 08:10 2014-07-19 08:10 · Answer 7 · 2014-07-19 08:10

Я думаю, что ответ @Basiloungas близок, но устарел (по крайней мере, на Mac).

Откройте файл ~/.gitconfig и установите safecrlf ложно

[core]
       autocrlf = input
       safecrlf = false

Это * заставит его игнорировать конец строки, по-видимому (работал для меня, во всяком случае).

35

Источник

user59947 19 июл '14 в 08:10

user664438 21 фев '12 в 10:08 2012-02-21 10:08 · Answer 8 · 2012-02-21 10:08

В VIM откройте файл (например: :e YOURFILEENTER), затем

:set noendofline binary
:wq

22

Источник

user664438 21 фев '12 в 10:08

user10245 15 дек '10 в 17:29 2010-12-15 17:29 · Answer 9 · 2010-12-15 17:29

У меня тоже была эта пробема.

SVN не выполняет преобразование конца строки, поэтому файлы фиксируются с неповрежденными окончаниями строки CRLF. Если вы затем используете git-svn, чтобы поместить проект в git, то окончания CRLF сохраняются в репозитории git, а это не то состояние, в котором git ожидает оказаться - по умолчанию используется только конец строки unix/linux (LF) зарегистрировано

Когда вы затем извлекаете файлы в Windows, преобразование autocrlf оставляет файлы нетронутыми (поскольку они уже имеют правильные окончания для текущей платформы), однако процесс, который решает, есть ли разница с проверенными файлами, выполняет обратное преобразование. перед сравнением, в результате чего сравнивается то, что он считает LF в извлеченном файле с неожиданным CRLF в хранилище.

Насколько я вижу, ваш выбор:

Повторно импортируйте ваш код в новый репозиторий git без использования git-svn, это будет означать, что окончания строк преобразуются в начальный git commit --all
Установите для autocrlf значение false и игнорируйте тот факт, что окончания строк не соответствуют предпочтительному стилю git.
Проверьте свои файлы с отключенным autocrlf, исправьте все окончания строк, проверьте все обратно и снова включите его.
Перепишите историю вашего репозитория, чтобы исходный коммит больше не содержал CRLF, которого git не ожидал. (Обычные предостережения о переписывании истории применимы)

Сноска: если вы выберете вариант №2, то, по моему опыту, некоторые из вспомогательных инструментов (ребаз, патч и т. Д.) Не справляются с файлами CRLF, и вы рано или поздно получите файлы со смесью CRLF и LF (несовместимая строка окончания). Я не знаю ни одного способа получить лучшее из обоих.

user659610 09 янв '13 в 09:36 2013-01-09 09:36 · Answer 10 · 2013-01-09 09:36

Удаление приведенного ниже из файла ~/.gitattributes

* text=auto

не позволит git проверять окончания строк в первую очередь.

18

Источник

user659610 09 янв '13 в 09:36

user6771814 17 май '20 в 12:43 2020-05-17 12:43 · Answer 11 · 2020-05-17 12:43

Большинство инструментов в Windows принимают только LF в текстовых файлах. Например, вы можете управлять поведением Visual Studio в файле с именем.editorconfig с помощью следующего примера содержимого (части):

 indent_style = space
 indent_size = 2
 end_of_line = lf    <<====
 charset = utf-8

Только оригинальный Windows-Notepad не работает с LF, но есть более подходящие простые инструменты для редактирования!

Следовательно, вы также должны использовать LF в текстовых файлах в Windows. Это мое сообщение, настоятельно рекомендуется! Нет причин использовать CRLF в Windows!

(В том же обсуждении используется \ in include paths в C/++, это чушь собачья, используйте #include с косой чертой!, это стандарт C/++, и все компиляторы Microsoft его поддерживают).

Следовательно, правильная настройка для git -

git config core.autocrlf false

Мое сообщение: забудьте о таких старых мыслящих программах, как dos2unix и unix2dos. Уточните у своей команды, что LF подходит для использования под Windows.

user3739540 09 дек '14 в 02:04 2014-12-09 02:04 · Answer 12 · 2014-12-09 02:04

http://www.rtuin.nl/2013/02/how-to-make-git-ignore-different-line-endings/

echo "* -crlf">.gitattributes

Сделайте это на отдельном коммите, или git может по-прежнему видеть целые файлы измененными при внесении одного изменения (в зависимости от того, была ли изменена опция autocrlf)

Этот действительно работает. Git будет уважать окончания строк в смешанных проектах окончания строк и не будет предупреждать вас о них.

user149391 27 дек '09 в 23:39 2009-12-27 23:39 · Answer 13 · 2009-12-27 23:39

Я не знаю много о git на Windows, но...

Мне кажется, что git конвертирует формат возврата, чтобы он соответствовал формату работающей платформы (Windows). CRLF является форматом возврата по умолчанию в Windows, в то время как LF является форматом возврата по умолчанию для большинства других ОС.

Скорее всего, формат возврата будет корректно настроен при переносе кода в другую систему. Я также считаю, что git достаточно умен, чтобы сохранить бинарные файлы в целости, а не пытаться конвертировать LF в CRLF, скажем, в JPEG.

Таким образом, вам, вероятно, не нужно слишком беспокоиться об этом преобразовании. Однако, если вы пойдете в архив своего проекта как tarball, коллеги-программисты, вероятно, оценят использование терминаторов строки LF, а не CRLF. В зависимости от того, насколько вы заботитесь (и в зависимости от того, используете ли вы Блокнот), вы можете настроить git на использование LF-возвратов, если можете:)

Приложение: CR - это код 13 ASCII, LF - это код ASCII 10. Таким образом, CRLF - это два байта, а LF - один.

user529187 16 июн '17 в 06:16 2017-06-16 06:16 · Answer 14 · 2017-06-16 06:16

Следует читать:

предупреждение: (Если вы проверите его или клонируете в другую папку с вашим текущим core.autocrlftrue,)LF будет заменен на CRLF
Файл будет иметь исходные окончания строк в вашем (текущем) рабочем каталоге.

Эта картина должна объяснить, что это значит.

12

Источник

user529187 16 июн '17 в 06:16

user1035056 16 дек '18 в 03:35 2018-12-16 03:35 · Answer 15 · 2018-12-16 03:35

Убедитесь, что вы установили последнюю версию git.
Я сделал как выше git config core.autocrlf false, когда использовался git (версия 2.7.1), но он не работал.
Тогда он работает сейчас при обновлении git (с 2.7.1 до 2.20.1).

9

Источник

user1035056 16 дек '18 в 03:35

user5139495 06 июл '21 в 15:39 2021-07-06 15:39 · Answer 16 · 2021-07-06 15:39

Другие ответы фантастичны для общей концепции. Я столкнулся с проблемой, когда после обновления предупреждение все еще появлялось в существующих репозиториях, которые были зафиксированы в предыдущей настройке.

Добавление с помощью --renormalize помогло, например

git add --renormalize .

Из документов:

«Применить« чистый »процесс заново ко всем отслеживаемым файлам, чтобы принудительно добавить их снова в индекс. Это полезно после изменения конфигурации core.autocrlf или текстового атрибута, чтобы исправить файлы, добавленные с неправильным окончанием строк CRLF / LF. Этот параметр подразумевает -u."

Tzouriel S. G. 23 мар '22 в 11:03 2022-03-23 11:03 · Answer 17 · 2022-03-23 11:03

У меня просто была такая же ошибка. Это произошло после установки NVM на Windows 10.

Настройка autoclrf на всех уровнях не сработала.
Я использовал в CMD: «git ls-files --eol»

      i/lf    w/crlf  attr/             src/components/quotes/ExQuoteForm.js
i/lf    w/lf    attr/                   src/components/quotes/HighlightedQuote.js

Вывод: файлы, которые я сделал, имеют другое окончание.

Чтобы изменить файлы и сбросить

      git config core.autocrlf false 
git rm --cached -r . 
git reset --hard

Альто: В некоторых проектах мне нужно было удалить репозиторий и запустить его заново.

user7394762 04 дек '18 в 10:41 2018-12-04 10:41 · Answer 18 · 2018-12-04 10:41

CRLF может вызвать некоторые проблемы при использовании вашего "кода" в двух разных ОС (Linux и Windows). Мой скрипт на python был написан в Docker-контейнере Linux, а затем передан с помощью Windows git-bash. Это дало мне предупреждение, что LF будет заменен CRLF. Я не задумывался об этом, но потом, когда я запустил сценарий позже, он сказал /usr/bin/env: 'python\r': No such file or directory, Теперь, когда \r для разветвления для вас. Windows использует "CR" - возврат каретки - поверх '\n' в качестве символа новой строки - \n\r, Это то, что вы могли бы рассмотреть.

user2862249 15 окт '13 в 11:33 2013-10-15 11:33 · Answer 19 · 2013-10-15 11:33

Откройте файл в Блокноте ++.
Перейти к Edit/EOL Conversion.
Нажмите на формат Windows.
Сохраните файл.

6

Источник

user2862249 15 окт '13 в 11:33

user947247 31 мар '15 в 14:39 2015-03-31 14:39 · Answer 20 · 2015-03-31 14:39

Вопрос OP касается окон, и я не мог использовать другие, не заходя в каталог или даже запуская файл в Notepad++, так как администратор не работал.. Поэтому пришлось пойти по этому пути:

C:\Program Files (x86)\Git\etc>git config --global core.autocrlf false

6

Источник

user947247 31 мар '15 в 14:39

user4722345 26 июн '18 в 18:51 2018-06-26 18:51 · Answer 21 · 2018-06-26 18:51

Многие текстовые редакторы позволяют вам перейти на LFсм. инструкции Atom ниже. Просто и понятно.

Нажмите CRLF справа внизу:

Выбрать LF в раскрывающемся списке сверху:

4

Источник

user4722345 26 июн '18 в 18:51

user490589 15 апр '11 в 06:33 2011-04-15 06:33 · Answer 22 · 2011-04-15 06:33

В командной строке GNU/Linux команды dos2unix и unix2dos позволяют легко конвертировать / форматировать файлы, поступающие из MS Windows.

3

Источник

user490589 15 апр '11 в 06:33

user12674966 21 июн '22 в 15:23 2022-06-21 15:23 · Answer 23 · 2022-06-21 15:23

CR и LF — это специальный набор символов, который помогает форматировать наш код.

CR (/r) помещает курсор в начало строки, но не создает новую строку. Вот как работает macOS.

LF (/n) создает новую строку, но не помещает курсор в начало этой строки. Курсор остается в конце последней строки. Так работают Unix и Linux.

CRLF (/r/f) создает новую строку, а также помещает курсор в начало новой строки. Так мы видим это в ОС Windows.

Обобщить:

LF (перевод строки)

означает перевод строки
обозначается / п
создает новую строку в коде
Код ASCII — 10.
Используется Unix и другими операционными системами, основанными на нем.

CR (ВОЗВРАТ КАРЕТКИ)

расшифровывается как ВОЗВРАТ КАРЕТКИ
обозначается / г
ставит курсор в начало строки.
Код ASCII — 13.
Используется macOS и ее предшественниками.

CRLF (ВОЗВРАТ КАРЕТКИ И ПЕРЕВОД СТРОКИ)

расшифровывается как CARRIAGE RETURN и LINE FEED
обозначается / n / r
создает новую строку и помещает курсор в начало этой новой строки.
Код ASCII: 10 для LF и 13 для CR.
В основном используется в ОС Windows.

Git по умолчанию использует LF. Поэтому, когда мы используем Git в Windows, он выдает предупреждение типа «CRLF будет заменен на LF» и автоматически преобразует все CRLF в LF, чтобы код стал совместимым.

NB: Не беспокойтесь... воспринимайте это не как предупреждение, а как уведомление.

user5138921 17 июл '23 в 20:40 2023-07-17 20:40 · Answer 24 · 2023-07-17 20:40

В Windows я получал это предупреждение, потому что имена моих файлов были слишком длинными. После переименования моих файлов во что-то более короткое (и перезапуска моего редактора VS Code) ошибка исчезла.

0

Источник

user5138921 17 июл '23 в 20:40

user8385813 13 июн '18 в 17:46 2018-06-13 17:46 · Answer 25 · 2018-06-13 17:46

Чтобы устранить проблему, т. Е. Чтобы избежать получения сообщений об ошибках

git config core.autocrlf false

Это для GitBash на Windows. Надеюсь, поможет:-)

0

Источник

user8385813 13 июн '18 в 17:46

user8126784 18 ноя '21 в 15:05 2021-11-18 15:05 · Answer 26 · 2021-11-18 15:05

у меня была такая же проблема, делал git add . && git resetВернул все окончания строк правильно

-2

Источник

user8126784 18 ноя '21 в 15:05