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

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

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

Концепция 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).

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

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

- autocrlf= true если в одном из ваших файлов есть lf в стиле Unix (= RARELY),
- autocrlf= input если в одном из ваших файлов есть crlf в стиле 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 в рабочем 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 для использования концов строк Windows),
- никогда не используйте core.autocrlf= input если у вас нет веских причин (например, если вы используете утилиты unix под windows или если у вас возникают проблемы с makefiles),

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

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

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

git rm --cached -r . 

и переписать индекс git с помощью

git reset --hard

https://help.github.com/articles/dealing-with-line-endings/#refreshing-a-repository-after-changing-line-endings

git config core.autocrlf false

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

unix2dos filename

или же

dos2unix -D filename

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

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

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

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

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

[core]
       autocrlf = input
       safecrlf = false

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

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

:set noendofline binary
:wq

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 служебные скрипты).

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

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

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

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

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

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

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

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

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

* text=auto

предотвратит проверку git строк строк на первом месте.

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

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

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

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

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

echo "* -crlf" > .gitattributes 

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

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

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

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

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

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

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

• Откройте файл в Notepad ++.
• Перейдите в Edit/EOL Conversion.
• Нажмите кнопку "Формат Windows".
• Сохраните файл.

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

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

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

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

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

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

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

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