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

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

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

git add -A

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

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

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

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

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

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

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

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

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

Здесь crlf= маркер конца строки в стиле win, lf= стиль unix (и mac osx).

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

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

    - autocrlf= trueесли у вас есть Unix-стиль lfв одном из ваших файлов (= RARELY),
    - autocrlf= inputесли у вас есть win-стиль 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и
   - «локальный» (для репо) 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.

У 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».

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

git config --global core.autocrlf input 

вы должны обновить индексы

git rm --cached -r . 

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

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. Если он говорит недействительным, используйте -f.

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

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

[core]
       autocrlf = input
       safecrlf = false

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

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

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

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

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

По сути, для такой смешанной среды, как у меня, настройка global 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

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

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

:set noendofline binary
:wq

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

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

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

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

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

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

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

* text=auto

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

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

предупреждение: ( Если вы проверите его или клонируете в другую папку с вашим текущим core.autocrlftrue ,) 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 - это код 13 ASCII, LF - это код ASCII 10. Таким образом, CRLF - это два байта, а LF - один.

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

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

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

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

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

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

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

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

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. Это то, что вы могли бы рассмотреть.

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

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

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

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

(То же самое обсуждение использует \ in include пути в C / ++, это фигня, используйте #include <pathTo / myheader.h> с косой чертой! Это стандарт C / ++, и все компиляторы Microsoft поддерживают его).

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

git config core.autocrlf false

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