CLRF (несогласованная ошибка окончания строки) [дубликат]

1. Откройте файл в Notepad ++.
2. Перейдите в Edit / EOL Conversion.
3. Нажмите в формате Windows.
4. Сохраните файл .

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

Концепция 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-style end-of-line marker, lf = unix-style (и mac osx).

(pre-osx cr не затронуто ни для одного из трех вариантов выше)

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

& nbsp; & nbsp; & nbsp; - autocrlf = true, если у вас есть unix-style lf в одном из ваших файлов (= RARELY), & nbsp; & nbsp; & nbsp; & nbsp; - autocrlf = input, если у вас есть win-style crlf в одном из ваших файлов (= почти ВСЕГДА), & nbsp; & nbsp; & nbsp; & nbsp; - autocrlf = false - НИКОГДА!

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

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

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

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

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

, где x является либо CRLF ( windows-style) или LF (unix-style), а стрелки обозначают

file to commit -> repository -> checked out file

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

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

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

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

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

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

Мораль (для Windows): & nbsp; & nbsp; & nbsp; - используйте core.autocrlf = true, если вы планируете использовать этот проект также в Unix (и не хотите настраивать свой редактор / IDE для использования окончаний строк unix), & nbsp; & nbsp; & nbsp; - использовать core.autocrlf = false, если вы планируете использовать этот проект только под Windows (или вы настроили ваш редактор / IDE для использования окончаний строк Unix) & nbsp; & nbsp; & nbsp; - never использовать core.autocrlf = input, если у вас нет веских причин (, например , если вы используете утилиты unix под окнами или если вы сталкиваетесь с проблемами make-файлов),

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

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

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

git config core.autocrlf false

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

Удаление из файла ~ / .gitattributes файла

* text=auto

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

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

[core]
       autocrlf = input
       safecrlf = false

A Статья 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 ).

Лучший выбор, который я нашел, - создать файлы per-repository .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

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

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

Нажмите CRLF в правом нижнем углу:

Выберите LF в выпадающем меню top:

Я мало знаю о git в Windows, но ...

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

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

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

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

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 для обновленной информации, которая включает значение «вход».

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

echo "* -crlf "> .gitattributes

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

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

В приглашении оболочки GNU / Linux dos2unix & amp; Команды unix2dos позволяют легко конвертировать / форматировать файлы из MS Windows

git config core.autocrlf false

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

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

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

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

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

As насколько я вижу, ваши варианты:

1. Повторно импортируйте свой код в новый репозиторий git без использования git-svn, это будет означать, что окончание строк преобразуется в intial git commit --all
2. Установите autocrlf в false и проигнорируйте тот факт, что окончание строк не соответствует предпочитаемому стилю git [/ g 4]
3. Проверьте свои файлы с помощью autocrlf, исправьте все окончания строки, верните все обратно и снова включите его.
4. Перезапишите историю вашего репозитория, чтобы исходная фиксация больше не содержала CRLF, которого git не ожидал. (Применяются обычные оговорки об истории перезаписи)

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

Он должен читать:

предупреждение: (Если вы проверите его / или клонируете в другую папку с текущим ядром.autocrlf, являющимся true,) LF будет заменен на CRLF

Файл будет иметь свои исходные концы строк в вашем текущем рабочем каталоге.

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

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

:set noendofline binary
:wq