Почему я должен использовать core.autocrlf = true в Git?

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

  1. Установите для core.autocrlf значение false везде,

  2. Следуйте инструкциям здесь (повторенным на страницах справки GitHub), чтобы преобразовать репозиторий, чтобы он содержал только строку LF- окончания, а затем установите для core.autocrlf значение true в Windows и input в OS X. Проблема с выполнением этого заключается в том, что если у меня есть какие-либо двоичные файлы в репозитории, которые:

    1. неправильно помечены как двоичные в gitattributes, а
    2. могут содержать оба CRLF и LF,

    они будут повреждены. Возможно, мой репозиторий содержит такие файлы.

Так почему бы мне просто не отключить Git-преобразование окончания строки? В сети много неясных предупреждений о том, что отключение core.autocrlf вызывает проблемы, но очень мало конкретных ; единственное, что я обнаружил до сих пор, это то, что kdiff3 не может обрабатывать окончания CRLF (для меня это не проблема), и что у некоторых текстовых редакторов есть проблемы с окончанием строки (также не проблема для меня).

Репозиторий является внутренним для моей компании, поэтому мне не нужно беспокоиться о том, чтобы поделиться им с людьми с разными настройками autocrlf или требованиями к окончанию строки.

Есть ли другие проблемы только с оставить окончание строк как есть, о чем я не знаю?


Единственные конкретные причины для установки autocrlf в true являются:

  • избегайте git status показывать все ваши файлы как измененные из-за автоматическое преобразование EOL, выполняемое при клонировании репозитория EOL Git на основе Unix в репозиторий Windows (например, см. проблему 83)
  • и ваши инструменты кодирования так или иначе зависят от собственный стиль EOL, присутствующий в вашем файле:
    • например, генератор кода, жестко запрограммированный для обнаружения собственного EOL
    • другие внешние партии (e xternal для вашего репо) с регулярным выражением или набором кода для обнаружения собственного EOL.
    • Я считаю, что некоторые плагины Eclipse могут создавать файлы с CRLF независимо от платформы, что может быть проблемой.
    • Вы кодируете Notepad.exe (если только вы не используете Windows 10 2018.09+, где Блокнот учитывает обнаруженный символ EOL).

Если только не вы можете увидеть конкретную обработку, которая должна иметь дело с собственным EOL, вам лучше оставить autocrlf на false ( git config --global core.autocrlf false ).

Обратите внимание, что эта конфигурация будет локальной (поскольку конфигурация не передается из репо в репо)

Если вы хотите, чтобы для всех пользователей, клонирующих это репо, была одинаковая конфигурация, ознакомьтесь с разделом «Какая лучшая стратегия обработки CRLF с помощью git?», используя текст в файле .gitattributes .

Пример:

   *. vcproj text eol = crlf * .sh text eol = lf  

Примечание. Начиная с git 2.8 (март 2016 г.), маркеры слияния будут больше не вводит смешанный конец строки (LF) в файле CRLF.
См. «Заставить Git использовать CRLF в его строках слияния«


45

Я разработчик .NET и уже много лет используют Git и Visual Studio. Я настоятельно рекомендую установить окончание строк в значение true. И сделайте это как можно раньше в течение срока службы вашего репозитория.

При этом я НЕНАВИЖУ, что Git меняет окончания моей строки. Система управления версиями должна сохранять и извлекать только ту работу, которую я делаю, но НЕ должна изменять ее. Когда-либо. Но это так.

Что произойдет, если у вас не будет для каждого разработчика установлено значение true, то ОДИН разработчик в конечном итоге установит значение true. Это приведет к изменению окончания строк всех ваших файлов на LF в вашем репо. И когда пользователи устанавливают ложную проверку их, Visual Studio предупредит вас и попросит изменить их. У вас очень быстро произойдут 2 вещи. Во-первых, вы будете получать все больше и больше предупреждений, чем больше ваша команда, тем больше вы будете получать. Вторая, что еще хуже, это то, что он покажет, что каждая строка каждого измененного файла была изменена (потому что окончание каждой строки будет изменено истинным парнем). В конце концов, вы больше не сможете надежно отслеживать изменения в своем репо. НАМНОГО проще и чище заставить всех придерживаться истины, чем пытаться оставить всех ложными. Как бы ужасно это ни было — жить с тем фактом, что ваша надежная система управления версиями делает то, чего не должна. Всегда.

Улучшение этот ответ
ответ дан 10 июня ’16 в 16: 23
  • Моя компания достаточно мала, чтобы мы могли легко потребовать, чтобы везде использовалось false, и я бы подумал, что более крупные компании могут сделать это с помощью политики, но я думаю, что это законная причина для использования «true», поэтому я поддерживаю так или иначе. Благодаря! — Rich 20 июня ’16 в 9:04
  • 1
    Проблема с выполнением этого с политикой (принудительное исполнение файла) заключается в том, что на компьютере с Windows вы можете иметь локальный, глобальный и скрытый файл конфигурации (ProgramData/Git/Confg). Вы можете принудительно применить локальный, проверив его в репо, но глобальные И скрытые файлы имеют приоритет. Также возможно, что локальные и глобальные (или скрытые) будут разными. В противном случае они будут конфликтовать друг с другом на ОДНОЙ машине, вызывая ошибки окончания строки там, где их нет. Это боль, которую нужно выследить. 🙁 — JGTaylor, 23 июня ’16, в 11:48
  • 7
    именно то, что я думаю. Это не задача системы управления версиями — возиться с файлами кода, как ему заблагорассудится. Окончание строк должно быть проблемой инструментов редактирования, не более того. — Тунджай Гёнджуоглу, 18 августа ‘ 16, 11:57
  • 9
    Если ваш проект предназначен только для Windows, проблем нет. Однако, если вы или ваши коллеги работаете на платформе * nix, ваша «настоятельная рекомендация» вызовет проблемы. Попробуйте запустить скрипт bash, perl или python с shebang, заканчивающимся на r n , и вы увидите. — phuclv 16 ноя 2016, в 9:38
  • 7
    Ситуация, которую вы описали как не проблема GIT, установите для параметра значение FALSE, как обычно, и оно исчезнет. Instad , это проблема в командной работе. Что это значит «в конечном итоге один разработчик устанавливает true «? Почему вообще вы им это позволяете? когда вы настраиваете их для доступа к репозиторию git, тогда точно так же, как вы не разрешаете загрязнять определенные области разными языками (так что любой, кто работает над этим, может это читать), или точно так же, как вы сохраняете ветки/слияния/перестановки/и т.д. policy, они должны получить четкое правило: установить правильную crlf. — quetzalcoatl 20 окт. ’17 в 8:07
| показать 6 дополнительных комментариев

Я разработчик .NET и использовал Git и Visual Studio для лет. Я настоятельно рекомендую установить окончание строк в значение true. И сделайте это как можно раньше в течение срока службы вашего репозитория.

При этом я НЕНАВИЖУ, что Git меняет окончания моей строки. Система управления версиями должна сохранять и извлекать только ту работу, которую я делаю, но НЕ должна изменять ее. Когда-либо. Но это так.

Что произойдет, если у вас не будет для каждого разработчика установлено значение true, то ОДИН разработчик в конечном итоге установит значение true. Это приведет к изменению окончания строк всех ваших файлов на LF в вашем репо. И когда пользователи устанавливают ложную проверку их, Visual Studio предупредит вас и попросит изменить их. У вас очень быстро произойдут 2 вещи. Во-первых, вы будете получать все больше и больше таких предупреждений, чем больше ваша команда, тем больше вы получите.. Вторая, что еще хуже, это то, что он покажет, что каждая строка каждого измененного файла была изменена (потому что окончание каждой строки будет изменено истинным парнем). В конце концов, вы больше не сможете надежно отслеживать изменения в своем репо. НАМНОГО проще и чище заставить всех придерживаться истины, чем пытаться оставить всех ложными. Как бы ужасно это ни было — жить с тем фактом, что ваша надежная система управления версиями делает то, чего не должна. Всегда.


12

Обновление 2 :

Xcode 9, похоже, имеет «особенность», при которой он игнорирует текущие окончания строки файла и вместо этого просто использует настройку окончания строки по умолчанию при вставке строк в файл, в результате чего получаются файлы со смешанными окончаниями строк.

Я почти уверен, что этой ошибки не было в Xcode 7; не уверен насчет Xcode 8. Хорошая новость заключается в том, что он, кажется, исправлен в Xcode 10.

На то время, когда он существовал, эта ошибка вызвала небольшое веселье в кодовой базе, о которой я упоминаю в вопрос (который по сей день использует autocrlf = false ) и привел ко многим сообщениям фиксации «EOL» и, в конечном итоге, к написанию мной git pre-commit ловушка для проверки/предотвращения появления смешанных окончаний строк.

Обновление :

Примечание. Как отмечает VonC, начиная с Git 2.8, маркеры слияния не вводят окончания строк в стиле Unix в файл в стиле Windows.

Оригинал :

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

 //Некоторый код   //Изменить A   ======  = //Изменить B   >>>>>>> Сохраненные изменения //Еще код    

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

Другая вещь * , которую мы обнаружили, заключается в том, что при использовании git diff для просмотра изменений в файле с Windows окончания строк, строки, которые были добавлены, отображают символы возврата каретки, таким образом:

 //Не изменено +//Новая строка добавлена ​​в ^ M + ^  M//Не изменено//Не изменено  

* На самом деле это не заслуживает термина: «проблема».

Улучшите этот ответ
отредактировал 5 февраля ’20 в 15:44
ответил 16 января ’12 в 16:50
  • 2
    NB Когда Visual Studio обнаруживает такой файл, она предлагает вам нормализовать окончания строк. Выбор либо окончания строк Windows, либо выбор not для нормализации концов строк работает нормально (поскольку VS по-прежнему отображает его правильно, оскорбительные строки будут удалены после разрешения конфликта). — Rich 16 янв. ’12 в 16:50
  • 2
    К сожалению, нацисты корпоративного контроля версий не согласны с этим (LF на маркерах конфликтов слияния) не является проблемой. — Ilia G 10 дек. ’13 в 15:16
  • 1
    Я согласен, что LF для маркеров конфликта слияния не должно быть проблемой. В любом случае эти строки не должны передаваться в репо. — ограбить 9 окт. В 15:19
  • 1
    Примечание: начиная с git 2.8 (март 2016 г.) маркеры слияния фактически будут иметь окончание строки CRLF. См. Stackoverflow.com/a/35474954/6309 — VonC 18 фев 2016, в 07:11
добавить комментарий |

Обновление 2 :

Xcode 9, похоже, имеет » функция «, где он будет игнорировать текущие окончания строки файла, а вместо этого просто использовать настройку окончания строки по умолчанию при вставке строк в файл, что приведет к файлам со смешанными окончаниями строк.

Я симпатичный уверен, что этой ошибки не было в Xcode 7; не уверен насчет Xcode 8. Хорошая новость заключается в том, что он, кажется, исправлен в Xcode 10.

На то время, когда он существовал, эта ошибка вызвала небольшое веселье в кодовой базе, о которой я упоминаю в вопрос (который по сей день использует autocrlf = false ) и привел ко многим сообщениям фиксации «EOL» и, в конечном итоге, к написанию мной git pre-commit ловушка для проверки/предотвращения появления смешанных окончаний строк.

Обновление :

Примечание. Как отмечает VonC, начиная с Git 2.8, маркеры слияния не вводят окончания строк в стиле Unix в файл в стиле Windows.

Оригинал :

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

 //Некоторый код   //Изменить A   ===  ==== //Изменить B   >>>>>>> Сохраненные изменения //Больше кода    

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

Другая вещь * , которую мы обнаружили, заключается в том, что при использовании git diff для просмотра изменений в файле с окончанием строки Windows, строки, которые были добавлены, отображают символы возврата каретки, таким образом:

 //Не изменено +//Новая строка добавлена ​​в ^ M + ^ M//Не  изменено//Не изменено  

* На самом деле это не заслуживает термина: «проблема».


0

Для меня.

Отредактируйте файл .gitattributes .

добавить

  *.  dll  

Тогда все идет хорошо.

Улучшите этот ответ
ответил 24 июля ’20 в 3:32
  • К сожалению, существует много бинарных файлов, не DLL в моем репозитории: чтобы быть уверенным, что я получил правильный список расширений файлов, которые нужно добавить в .gitattributes , потребуется просмотреть десятки тысяч файлов . — Rich 31 июл. ’20 в 21:34
добавить комментарий |

Для меня.

Отредактируйте файл .gitattributes.

добавьте

*.dll двоичный  

Тогда все идет хорошо.



git config core.autocrlf по умолчанию должен быть false

И это должно быть настроено в действии проверки. По умолчанию должно быть false; в противном случае git checkout в Windows часто будет пытаться превратить окончания строк LF в CRLF, что может легко сломать хрупкие файлы, такие как ожидаемые выходные файлы для тестов.

См. https://travis-ci. community/t/files-in-checkout-have-eol-changed-from-lf-to-crlf/349 для того же потока на Travis CI, который так и не получил исправления.

I пришлось обойти это с помощью файла .gitattributes следующим образом:

  * -text  

Настройка вашего окончание строки файлом .gitattributes — это правильное решение, так как это единственный способ проверить конфигурацию окончания строки в репозитории.

На протяжении многих лет рекомендации относительно рекомендаций были неоднозначными. для ядра. autocrlf, но большинство предложило core.autocrlf = true. Что наиболее важно, Git для Windows устанавливает core.autocrlf = true в установщике. Поэтому мы также установили core.autocrlf = true по умолчанию.

Однако вы не должны полагаться на настройки core.autocrlf, вы должны настроить поведение, которое вы хотите, с помощью файла .gitattributes. Это единственный способ надежно справиться с окончаниями строк в репозитории.


Спасибо за ответ. Приятно знать, что, по крайней мере, это было осознанное решение.

Я все же считаю, что это неправильное решение. autocrlf предназначен для людей, но GitHub Actions не для людей. Он должен проверить репозиторий * в точности * в том виде, в котором он был найден.

Я бы сказал обратное; если кто-то действительно хочет, чтобы autocrlf работал на CI, они должны как-то его включить.

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


Полностью согласен с OP. Этот параметр очень громоздкий, и мы хотели бы иметь возможность его настроить, чтобы мы могли снова его отключить.


@mvdan писал:

Спасибо за ответ. Приятно знать, что, по крайней мере, это было сознательное решение.

Я все еще я думаю, что это неправильное решение. autocrlf предназначен для людей, но GitHub Actions — это не человек. Он должен проверить репозиторий * в точности * в том виде, в каком он был найден.

Я бы сказал обратное; если кто-то действительно хочет, чтобы autocrlf выполнялся на CI, он должен как-то его включить.

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

Это! Это может вызвать серьезные проблемы! Пожалуйста, подумайте еще раз.


Привет,

Как мне найти соответствие

   core.autocrlf = false  

через конфигурацию .gitattributes?

Я не совсем понимаю этот документ.

Спасибо


К вашему сведению, дубликат был зарегистрирован как проблема на GitHub: https://github.com/actions/checkout/issues/135


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

Не обязательно — используйте файл глобальных атрибутов git. Пример для компьютера с Windows:

.gitconfig

  [core] attributesfile = C: \ Users  \ thdoan \ Documents \ gitattributes_global.txt  

Файл gitattributes предназначен для CI, а не для локального компьютера, поэтому ваше решение не применяется.

Оцените статью
logicle.ru
Добавить комментарий