git замінює LF на CRLF

Запуск git на машині Windows XP, використовуючи bash. Я експортував свій проект із SVN, а потім клонував оголене сховище.

Потім я вставив експорт у каталог голих сховищ і зробив:

git add -A

Потім я отримав список повідомлень:

LF буде замінено CRLF

Які наслідки цього перетворення? Це рішення .NET у Visual Studio.

Ці повідомлення через неправильне значення за замовчуванням core.autocrlf у Windows.

Концепція 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-style (та mac osx).

(pre-osx crне впливає на жоден із трьох варіантів, наведених вище)

Коли з’являється це попередження (під Windows)

    - autocrlf= trueякщо ви маєте стиль Unix lfв одному зі своїх файлів (= РІДНО),
    - autocrlf= inputякщо у вас є стиль win crlfв одному з ваших файлів (= майже ВЖЕ),
    - autocrlf= false- НІКОЛИ!

Що означає це попередження

Попередження " LF буде замінено CRLF " говорить, що ви (маючи autocrlf=true ) втратите свій LF у стилі unix після циклу оформлення замовлення (він буде замінений на CRLF у стилі Windows). Git не сподівається на те, що ви використовуєте LF у стилі unix під вікнами.

Попередження " 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та
   - "локальний" (per-repo) gitconfig .git/configу робочому режимі.

Отже, напишіть git config core.autocrlfу робочий dir, щоб перевірити поточно використане значення та

   - додати autocrlf=falseдо загальносистемного рішення gitconfig # за системою
   - git config --global core.autocrlf false            # рішення на користувача
   - git config --local core.autocrlf false              # рішення за проект

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

Мораль (для Windows):
    - use core.autocrlf= trueякщо ви плануєте використовувати цей проект також під Unix (і не бажаєте конфігурувати редактор / IDE для використання закінчень рядків Unix),
    - use 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 repo, який 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 для оновленої інформації, що включає значення "введення".

Якщо ви вже перевірили код, файли вже індексуються. Після зміни налаштувань git скажіть:

git config --global core.autocrlf input 

вам слід оновити індекси

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. Якщо він каже недійсний, тоді використовуйте -f.

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

Відкрийте файл ~ / .gitconfig і встановіть safecrlfзначення false

[core]
       autocrlf = input
       safecrlf = false

Це * змусить ігнорувати кінець рядка char очевидно (все одно для мене працювало).

Стаття 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

Налаштувати трохи більше речей, але робити це один раз за проект, і будь-який учасник, який працює на будь-якій ОС, не повинен мати проблем із закінченнями рядків під час роботи з цим проектом.

Відкрийте файл 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, це означатиме, що закінчення рядків перетворюються в Inicial git-коміті - всі
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.

Підсумовуючи це, напевно, вам не потрібно занадто сильно хвилюватися над цією конверсією. Однак, якщо ви збираєтесь архівувати свій проект у вигляді тарболу, колеги-кодери, ймовірно, будуть вдячні мати лінійні термінатори, а не CRLF. Залежно від того, скільки ви дбаєте (і залежно від того, що ви не використовуєте Блокнот), ви можете встановити, що git використовує повернення LF, якщо можете :)

Додаток: CR - код ASCII 13, LF - код ASCII 10. Таким чином, CRLF - це два байти, тоді як LF - один.

Переконайтеся, що ви встановили найновіший git.
Я робив як вище git config core.autocrlf false, коли використовував git (версія 2.7.1), але це не спрацювало.
Тоді він працює зараз, коли оновлення git (з 2.7.1 до 2.20.1).

1. Відкрийте файл у Блокноті ++.
2. Перейдіть до редагування / редагування EOL.
3. Клацніть на Формат Windows.
4. Збережіть файл.

Питання OP пов'язане з Windows, і я не міг використовувати інших, не переходячи до каталогу або навіть запустивши файл у 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 приймає лише текстові файли у текстових файлах. Наприклад, ви можете керувати поведінкою Visual Studio у файлі під назвою '.editorconfig' із таким прикладом вмісту (частини):

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

Тільки оригінальний блокнот Windows не працює з LF, але є ще кілька належних простих інструментів редактора!

Отже, ви повинні використовувати LF і в текстових файлах у Windows. Це моє повідомлення, рекомендовано строгі! Немає підстав використовувати CRLF у Windows!

(У тій же дискусії використовується \ in include paths у C / ++; це фігня, використовуйте #include <pathTo / myheader.h> з косою рисою! Це стандарт C / ++ і всі компілятори microsoft підтримують його).

Отже, правильна настройка git

git config core.autocrlf false

Моє повідомлення: Забудьте про такі старі програми мислення, як dos2unix та unix2dos. Поясніть у своїй команді, що LF належним чином використовувати під Windows.