Я попытался зафиксировать файлы с CRLF-оканчивающимися строками, но это не удалось.

Я провел целый рабочий день на своем компьютере с Windows, пробуя разные стратегии, и был почти не в силах прекратить попытки использовать Git и вместо этого попробовать Mercurial .

Пожалуйста, поделитесь только одним лучшим опытом для ответа.

Спустя почти четыре года после того, как я задал этот вопрос, я наконец нашел ответ, который меня полностью устраивает !

Подробности смотрите в github: справочное руководство по работе с окончаниями строк .

Git позволяет вам установить конечные свойства строки для репо, используя атрибут text в .gitattributesфайле. Этот файл фиксируется в репозитории и переопределяет core.autocrlfнастройку, позволяя вам обеспечить согласованное поведение для всех пользователей независимо от их настроек git.

И поэтому

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

Вот пример .gitattributesфайла

# Auto detect text files and perform LF normalization
*        text=auto

*.cs     text diff=csharp
*.java   text diff=java
*.html   text diff=html
*.css    text
*.js     text
*.sql    text

*.csproj text merge=union
*.sln    text merge=union eol=crlf

*.docx   diff=astextplain
*.DOCX   diff=astextplain

# absolute paths are ok, as are globs
/**/postinst* text eol=lf

# paths that don't start with / are treated relative to the .gitattributes folder
relative/path/*.txt text eol=lf

Существует удобная коллекция готовых к использованию файлов .gitattributes для самых популярных языков программирования. Это полезно для начала.

После того, как вы создали или скорректировали свою .gitattributes, вы должны выполнить повторную нормализацию окончаний строки раз и навсегда .

Обратите внимание, что приложение GitHub Desktop может предложить и создать .gitattributesфайл после открытия репозитория Git вашего проекта в приложении. Чтобы попробовать это, щелкните значок шестеренки (в правом верхнем углу)> Настройки репозитория ...> Концы строк и атрибуты. Вам будет предложено добавить рекомендуемые .gitattributesи, если вы согласны, приложение также выполнит нормализацию всех файлов в вашем хранилище.

Наконец, в статье « Разум в конце своей строки» содержится дополнительная справочная информация и объясняется, как Git развивался в рассматриваемых вопросах. Я считаю это обязательным чтением .

Возможно, в вашей команде есть пользователи, которые используют EGit или JGit (такие инструменты, как Eclipse и TeamCity используют их) для фиксации своих изменений. Тогда вам не повезло, как объясняет @gatinueta в комментариях к этому ответу:

Этот параметр не удовлетворит вас полностью, если в вашей команде есть люди, работающие с Egit или JGit, поскольку эти инструменты будут просто игнорировать .gitattributes и с радостью проверять файлы CRLF https://bugs.eclipse.org/bugs/show_bug.cgi? ID = 342372

Одна хитрость может заключаться в том, чтобы они зафиксировали свои изменения в другом клиенте, скажем SourceTree . В то время наша команда предпочитала этот инструмент EGip для Eclipse во многих случаях.

Кто сказал, что программное обеспечение легко? : - /

Не конвертируйте окончания строк. Это не работа VCS, чтобы интерпретировать данные - просто сохраните и версируйте их. Каждый современный текстовый редактор в любом случае может читать оба вида окончаний строк.

Вы почти всегда хотите, autocrlf=inputесли вы действительно не знаете, что делаете.

Некоторый дополнительный контекст ниже:

Это должно быть, core.autocrlf=trueесли вам нравится конец DOS или core.autocrlf=inputвы предпочитаете unix-newlines. В обоих случаях ваш репозиторий Git будет иметь только LF, что является правильным. Единственным аргументом для этого core.autocrlf=falseбыло то, что автоматическая эвристика может некорректно определять некоторый двоичный файл как текст, и тогда ваша плитка будет повреждена. Таким образом, core.safecrlfбыла введена опция для предупреждения пользователя в случае необратимого изменения. На самом деле, есть две возможности необратимых изменений - смешивание конца строки в текстовом файле, при этом нормализация желательна, поэтому это предупреждение можно игнорировать или (очень маловероятно), что Git неправильно определил ваш двоичный файл как текст. Затем вам нужно использовать атрибуты, чтобы сообщить Git, что этот файл является двоичным.

Вышеупомянутый абзац изначально был извлечен из потока на gmane.org, но с тех пор он отключился

Две альтернативные стратегии для согласования окончаний строк в смешанных средах (Microsoft + Linux + Mac):

A. Глобальная настройка для всех репозиториев

1) Конвертировать все в один формат

find . -type f -not -path "./.git/*" -exec dos2unix {} \;
git commit -a -m 'dos2unix conversion'

2) Установите core.autocrlfв inputLinux / UNIX или trueв MS Windows (репозиторий или глобальный)

git config --global core.autocrlf input

3) [Необязательно] установите core.safecrlfв true(чтобы остановить) или warn(чтобы петь :), чтобы добавить дополнительное охранное сравнение, если обратное преобразование новой строки приведет к тому же файлу

git config --global core.safecrlf true

Б. Или для каждого хранилища

1) Конвертировать все в один формат

find . -type f -not -path "./.git/*" -exec dos2unix {} \;
git commit -a -m 'dos2unix conversion'

2) добавить .gitattributesфайл в свой репозиторий

echo "* text=auto" > .gitattributes
git add .gitattributes
git commit -m 'adding .gitattributes for unified line-ending'

Не беспокойтесь о ваших двоичных файлах - Git должен быть достаточно умным с ними.

Подробнее о переменных safecrlf / autocrlf

Попробуйте установить core.autocrlfопцию конфигурации в true. Также посмотрите на core.safecrlfвариант.

На самом деле это звучит так, как будто это core.safecrlfможет быть уже установлено в вашем хранилище, потому что (выделение мое):

Если это не относится к текущим настройкам core.autocrlf, git отклонит файл .

Если это так, то вы можете проверить, что ваш текстовый редактор настроен на последовательное использование концов строк. Скорее всего, вы столкнетесь с проблемами, если текстовый файл будет содержать сочетания концов строк LF и CRLF.

Наконец, я чувствую, что рекомендация просто «использовать то, что вам дано» и использовать строки с ограничением LF в Windows, вызовет больше проблем, чем решит. У Git есть вышеупомянутые опции, чтобы попытаться обработать окончания строк разумным способом, поэтому имеет смысл использовать их.

Использование core.autocrlf=falseпрекратило помечать все файлы как обновленные, как только я проверил их в своем проекте Visual Studio 2010 . Два других члена команды разработчиков также используют системы Windows, поэтому смешанная среда не вступила в игру, но настройки по умолчанию, поставляемые с хранилищем, всегда отмечали все файлы как обновленные сразу после клонирования.

Я думаю, суть в том, чтобы найти, какой параметр CRLF работает для вашей среды. Тем более что во многих других репозиториях на наших установках Linux ящики autocrlf = trueдают лучшие результаты.

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

Это две опции для пользователей Windows и Visual Studio, которые делятся кодом с пользователями Mac или Linux . Для более подробного объяснения прочитайте руководство по gitattributes .

* текст = авто

В .gitattributesфайле вашего репо добавьте:

*   text=auto

Это нормализует все файлы с LFокончаниями строк в репо.

И в зависимости от вашей операционной системы ( core.eolнастройки) файлы в рабочем дереве будут нормализованы LFдля систем CRLFна основе Unix или для систем Windows.

Это конфигурация, которую используют репозитории Microsoft .NET .

Пример:

Hello\r\nWorld

Будет нормализовано в репо всегда так:

Hello\nWorld

При оформлении заказа рабочее дерево в Windows будет преобразовано в:

Hello\r\nWorld

На кассе рабочее дерево в Mac останется как:

Hello\nWorld

Примечание. Если в вашем репозитории уже есть файлы, которые не были нормализованы, git statusэти файлы будут показаны как полностью измененные в следующий раз, когда вы внесете в них какие-либо изменения, и другим пользователям будет неудобно объединять их изменения позже. См. Обновление хранилища после изменения концов строк для получения дополнительной информации.

core.autocrlf = true

Если textв .gitattributesфайле не указано иное, Git использует core.autocrlfпеременную конфигурации, чтобы определить, нужно ли конвертировать файл.

Для пользователей Windows git config --global core.autocrlf trueэто отличный вариант, потому что:

• Файлы нормализуются по LFокончанию строк только при добавлении в репо. Если в репо есть файлы, которые не нормализованы, этот параметр не коснется их.
• Все текстовые файлы преобразуются в CRLFокончания строк в рабочем каталоге.

Проблема с этим подходом заключается в том, что:

• Если вы являетесь пользователем Windows autocrlf = input, вы увидите множество файлов с LFокончаниями строк. Не представляет опасности для остальной части команды, потому что ваши коммиты все равно будут нормализованы с LFокончанием строки.
• Если вы являетесь пользователем Windows core.autocrlf = false, вы увидите группу файлов с LFокончаниями строк и можете добавить файлы с окончаниями CRLFстрок в репозиторий.
• Большинство пользователей Mac используют autocrlf = inputи могут получать файлы с CRLFокончаниями файлов, вероятно, от пользователей Windows core.autocrlf = false.

--- ОБНОВЛЕНИЕ 3 --- (не конфликтует с ОБНОВЛЕНИЕМ 2)

Учитывая тот случай, когда пользователи Windows предпочитают работать, CRLFа пользователи Linux / Mac предпочитают работать LFс текстовыми файлами. Предоставление ответа с точки зрения сопровождающего хранилища :

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

Постановка - это то, что многие люди путают, пытаясь понять, как работают стратегии новой строки . Важно выбрать следующие моменты, прежде чем выбрать правильное значение для core.autocrlfсвойства:

• Добавление текстового файла для фиксации ( постановка ) аналогично копированию файла в другое место внутри .git/подкаталога с преобразованными окончаниями строк (в зависимости от core.autocrlfзначения в конфигурации клиента). Все это делается локально.
• Настройка core.autocrlfаналогична предоставлению ответа на вопрос (точно такой же вопрос на всех ОС):
  • «Должен ли git-клиент a. Преобразовывать LF-в-CRLF при извлечении (извлечении) изменений из репозитория с удаленного компьютера или b. Преобразовывать CRLF-в-LF при добавлении файла для фиксации? » И возможные ответы (значения) находятся:
  • false:"не делай ничего из вышеперечисленного ",
  • input:" делай только б "
  • true: " сделать а и б "
  • обратите внимание, что нет " сделать только "

к счастью

• Настройки клиента git (windows:, core.autocrlf: truelinux / mac:) core.autocrlf: falseбудут совместимы со стратегией LF-only-repo .
  Значение : клиенты Windows по умолчанию преобразуются в CRLF при извлечении из хранилища и преобразуются в LF при добавлении для фиксации. И клиенты Linux по умолчанию не будут делать никаких преобразований. Это теоретически сохраняет ваш репо только для жизни.

К несчастью:

• Могут быть клиенты GUI, которые не уважают core.autocrlfзначение git
• Могут быть люди, которые не используют значение для уважения вашей стратегии lf-repo. Например, они используют core.autocrlf=falseи добавляют файл с CRLF для фиксации.

Чтобы обнаружить текстовые файлы не как lf, зафиксированные указанными выше клиентами, вы можете следовать инструкциям, приведенным в --- update 2 ---: ( git grep -I --files-with-matches --perl-regexp '\r' HEADна клиенте, скомпилированном с использованием: --with-libpcreflag)

А вот и подвох . Я, как сопровождающий, храню git.autocrlf=inputрепозиторий, чтобы я мог исправить любые ошибочно зафиксированные файлы, просто добавив их снова для фиксации. И я предоставляю текст коммита: «Исправление неверно зафиксированных файлов».

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

*.java          text !eol # Don't do auto-detection. Treat as text (don't set any eol rule. use client's)
*.jpg           -text     # Don't do auto-detection. Treat as binary
*.sh            text eol=lf # Don't do auto-detection. Treat as text. Checkout and add with eol=lf
*.bat           text eol=crlf # Treat as text. Checkout and add with eol=crlf

Вопрос: Но почему мы вообще заинтересованы в стратегии обработки новой строки?

Ответ. Чтобы избежать фиксации изменения одной буквы, отображается изменение в 5000 строк только потому, что клиент, выполнивший изменение, автоматически преобразовал полный файл из crlf в lf (или наоборот) перед добавлением его для фиксации. Это может быть довольно болезненным, когда вовлечено разрешение конфликта . Или это может быть в некоторых случаях причиной необоснованных конфликтов.

--- ОБНОВЛЕНИЕ 2 ---

По умолчанию клиент git будет работать в большинстве случаев. Даже если у вас есть только клиенты Windows, только клиенты Linux или оба. Эти:

• windows: core.autocrlf=true означает преобразование строк в CRLF при оформлении заказа и преобразование строк в LF при добавлении файлов.
• linux: core.autocrlf=input означает, что не нужно конвертировать строки при оформлении заказа (в этом нет необходимости, поскольку ожидается, что файлы будут зафиксированы с помощью LF), а конвертировать строки в LF (если необходимо) при добавлении файлов. ( - update3 - : кажется, что это falseпо умолчанию, но опять же все в порядке)

Свойство может быть установлено в разных областях. Я бы предложил явно указать в области --globalдействия, чтобы избежать некоторых проблем IDE, описанных в конце.

git config core.autocrlf
git config --global core.autocrlf
git config --system core.autocrlf
git config --local core.autocrlf
git config --show-origin core.autocrlf

Также я бы настоятельно не рекомендовал использовать в Windows git config --global core.autocrlf false (если у вас есть клиенты только для Windows), в отличие от того, что предлагается для git документации . Установка в false приведет к фиксации файлов с CRLF в репо. Но на самом деле нет причин. Вы никогда не знаете, нужно ли вам делиться проектом с пользователями Linux. Плюс это один дополнительный шаг для каждого клиента, который присоединяется к проекту, вместо использования значений по умолчанию.

Теперь для некоторых особых случаев файлов (например *.bat *.sh), которые вы хотите, чтобы они были извлечены с помощью LF или CRLF, вы можете использовать.gitattributes

Подводя итог для меня, лучшая практика :

• Убедитесь, что каждый недвоичный файл фиксируется с помощью LF в git repo (поведение по умолчанию).
• Используйте эту команду, чтобы убедиться, что никакие файлы не фиксируются с помощью CRLF: git grep -I --files-with-matches --perl-regexp '\r' HEAD( Примечание: на клиентах Windows работает только через git-bashклиентов Linux и только на клиентах Linux, если они скомпилированы с использованием --with-libpcrein ./configure).
• Если вы нашли такие файлы, выполнив приведенную выше команду, исправьте их. Это включает в себя (по крайней мере, в Linux):
  • установить core.autocrlf=input( --- обновление 3 - )
  • изменить файл
  • отменить изменение (файл все еще отображается как измененный)
  • совершить это
• Используйте только минимум .gitattributes
• Попросите пользователей установить core.autocrlfописанные выше значения по умолчанию.
• Не рассчитывайте на 100% на наличие .gitattributes. git-клиенты IDE могут игнорировать их или обращаться с ними по-разному.

Как уже было сказано, некоторые вещи могут быть добавлены в атрибуты git:

# Always checkout with LF
*.sh            text eol=lf
# Always checkout with CRLF
*.bat           text eol=crlf

Я думаю, что некоторые другие безопасные варианты .gitattributesвместо использования автоопределения для двоичных файлов:

• -text(например, для *.zipили *.jpgфайлов: не будет рассматриваться как текст. Таким образом, преобразование в конце строки не будет предприниматься. Различия могут быть возможны через программы преобразования)
• text !eol(например , для *.java, *.html:.. Лечили как текст, но предпочтение EOL стиль не установлен Так настройка клиента используется)
• -text -diff -merge(например, для *.hugefile: Не обрабатывается как текст. Дифф / слияние невозможно)

--- ПРЕДЫДУЩЕЕ ОБНОВЛЕНИЕ ---

Один болезненный пример клиента, который ошибочно фиксирует файлы:

NetBeans 8.2 (на окнах), будет неправильно совершать все текстовые файлы с CRLFs, если вы не в явном виде установить core.autocrlfкак глобальные . Это противоречит стандартному поведению клиента git и вызывает много проблем позже при обновлении / слиянии. Это то, что заставляет некоторые файлы выглядеть по-разному (хотя это не так), даже когда вы возвращаетесь .
Такое же поведение в NetBeans происходит, даже если вы правильно добавили .gitattributesв свой проект.

Использование следующей команды после фиксации, по крайней мере, поможет вам определить, есть ли у вашего git-репо проблемы с окончанием строки: git grep -I --files-with-matches --perl-regexp '\r' HEAD

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

Используйте следующие anti-CRLFдезинфицирующие средства.

• клиенты windows / linux: core.autocrlf=input

• совершено .gitattributes: * text=auto eol=lf

• commit .editorconfig( http://editorconfig.org/ ), который является своего рода стандартизированным форматом в сочетании с плагинами редактора:

  • https://github.com/editorconfig/
  • https://github.com/welovecoding/editorconfig-netbeans/

Это просто обходное решение:

В обычных случаях используйте решения, которые поставляются с git. Они прекрасно работают в большинстве случаев. Принудительно LF, если вы делитесь разработкой в ​​системах на базе Windows и Unix, устанавливая .gitattributes .

В моем случае> 10 программистов разрабатывали проект в Windows. Этот проект был проверен с CRLF, и не было никакой возможности, чтобы заставить LF.

Некоторые настройки были написаны на моем компьютере без какого-либо влияния на формат LF; таким образом, некоторые файлы глобально менялись на LF при каждом небольшом изменении файла.

Мое решение:

Windows-машины: пусть все как есть. Ничего не волнует, так как вы являетесь разработчиком окон «одинокий волк» по умолчанию, и вам приходится обращаться с этим так: «В широком мире нет другой системы, не так ли?»

Unix-машины

1. Добавьте следующие строки в [alias]раздел конфигурации . Эта команда выводит список всех измененных (т.е. измененных / новых) файлов:

   lc = "!f() { git status --porcelain \
                | egrep -r \"^(\?| ).\*\\(.[a-zA-Z])*\" \
                | cut -c 4- ; }; f "

2. Преобразуйте все эти измененные файлы в формат DOS:

   unix2dos $(git lc)

3. По выбору ...

   1. Создайте git hook для этого действия, чтобы автоматизировать этот процесс

   2. Используйте params, включите его и измените grepфункцию, чтобы она соответствовала только определенным именам файлов, например:

      ... | egrep -r "^(\?| ).*\.(txt|conf)" | ...

   3. Не стесняйтесь делать это еще удобнее, используя дополнительные ярлыки:

      c2dos = "!f() { unix2dos $(git lc) ; }; f "

      ... и запустить преобразованный материал, набрав

      git c2dos