Чому я повинен використовувати core.autocrlf = true у Git?

У мене є сховище Git, до якого можна отримати доступ як з Windows, так і з ОС X, і я знаю, що він містить деякі файли із закінченнями рядків CRLF. Наскільки я можу сказати, з цим вирішити два способи:

1. Набір core.autocrlfдля falseвсюди,

2. Виконайте тут інструкції (наголошуються на довідкових сторінках GitHub), щоб конвертувати сховище, щоб він містив лише закінчення рядків LF, а потім встановлено core.autocrlfв trueWindows та inputOS X. Проблема з цим полягає в тому, що якщо у мене є будь-які бінарні файли у сховищі що:

   1. неправильно позначені як двійкові в gitattributes, і
   2. містять як CRLF, так і LF,

   вони будуть зіпсовані. Можливо, моє сховище містить такі файли.

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

Репозиторій є внутрішнім для моєї компанії, і тому мені не потрібно переживати, щоб ділитися ним з людьми з різними налаштуваннями автопосилання або вимогами до закінчення рядків.

Чи є якісь інші проблеми з тим, щоб просто залишити закінчення рядків як - це я не знаю?

Єдині конкретні причини , щоб встановити autocrlfна trueнаступні:

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

Якщо ви не можете побачити специфічне лікування, яке повинно мати справу з нативним EOL, вам краще залишитись autocrlfнаfalse ( git config --global core.autocrlf false).

Зауважте, що ця конфігурація була б локальною (оскільки конфігурація не висувається з репо в репо)

Якщо ви хочете однакову конфігурацію для всіх користувачів, які клонують репо, перевірте " Яка найкраща CRLFстратегія обробки з git? ", Використовуючи textатрибут у .gitattributesфайлі .

Приклад:

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

Примітка: починаючи з git 2.8 (березень 2016 р.), Маркери злиття більше не вводять змішане закінчення рядка (LF) у файл CRLF.
Див. " Зробити Git використовувати CRLF на його лініях" <<<<<<< HEAD " "

Я розробник .NET і роками використовую Git та Visual Studio. Моя рішуча рекомендація - встановити закінчення рядків на істинні. І робіть це якомога раніше, протягом життя вашого сховища.

Коли це було сказано, Я НЕЮ Я, що Git змінює мої закінчення рядка. Елемент керування джерелом повинен зберігати та відновлювати роботу, яку я виконую, він НЕ повинен змінювати її. Колись. Але це робить.

Що станеться, якщо у вас не буде встановлено значення кожного істинного розробника, якщо ОДИН розробник врешті-решт встановить значення true. Це почне змінювати закінчення рядків усіх ваших файлів на LF у вашому репо. І коли користувачі встановлять помилкові перевірки, випуск Visual Studio попередить вас і попросить змінити їх. У вас буде 2 речі, які відбудуться дуже швидко. По-перше, ви отримаєте все більше і більше цих попереджень, чим більше буде ваша команда, тим більше ви отримаєте. Друга, і гірша річ, що це покаже, що кожен рядок кожного зміненого файлу був змінений (адже закінчення рядків кожного рядка буде змінено справжнім хлопцем). Зрештою, ви більше не зможете надійно відслідковувати зміни у вашому репо. Набагато простіше і чіткіше зробити так, щоб всі трималися правдивими, ніж намагатися не допустити до помилок. Настільки жахливо, як жити з тим фактом, що ваш контрольований джерело контролю робить щось, чого не повинен. Колись.

Оновлення 2 :

Здається, що в Xcode 9 є "особливість", коли він буде ігнорувати поточні закінчення файлу файлу, а замість цього просто використовувати налаштування для закінчення рядка за замовчуванням під час вставлення рядків у файл, в результаті чого утворюються файли зі змішаними закінченнями рядків.

Я майже впевнений, що ця помилка не існувала в Xcode 7; не впевнений у Xcode 8. Хороша новина полягає в тому, що він, мабуть, фіксований у Xcode 10.

За час існування ця помилка спричинила невелику кількість веселощів у кодовій базі, про яку я згадую у запитанні (яку до цього часу використовує autocrlf=false), і призвела до того, що багато "EOL" передають повідомлення і, врешті-решт, до мого написання git pre-commithook перевірити для / запобігання введенню змішаних закінчень рядків.

Оновлення :

Примітка: Як було відзначено VonC, починаючи з Git 2.8, маркери злиття буде НЕ вводити Unix-стиль завершень рядків в файл для Windows-стилі .

Оригінал :

Один невеликий ікони, який я помітив під час цього налаштування, - це те, що коли виникають конфлікти злиття, рядки git додають для позначення відмінностей не мають закінчень рядків Windows, навіть коли решта файлу є, і ви можете закінчити з файлом із змішаними закінченнями рядків, наприклад:

// Some code<CR><LF>
<<<<<<< Updated upstream<LF>
// Change A<CR><LF>
=======<LF>
// Change B<CR><LF>
>>>>>>> Stashed changes<LF>
// More code<CR><LF>

Це не викликає у нас жодних проблем (я думаю, будь-який інструмент, який може працювати з обома типами закінчень рядків, також матиме розумний варіант із змішаними закінченнями рядків - звичайно, всі ті, що ми використовуємо), але це щось, що слід пам’ятати.

Інша річ ^{*, яку} ми знайшли, - це те, що при використанні git diffдля перегляду змін у файлі, який має закінчення рядків Windows, додані рядки відображають повернення каретки, таким чином:

    // Not changed

+   // New line added in^M
+^M
    // Not changed
    // Not changed

_{* Це дійсно не заслуговує на термін: "питання".}