Какова лучшая стратегия обработки CRLF (возврат каретки, перевод строки) с Git?

598

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

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

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

Даниэль Джомф
источник

Ответы:

753

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

Подробности смотрите в 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 во многих случаях.

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

Даниэль Джомф
источник
7
Хотите поделиться Windows .gitattributes?
полковник Паник
Как узнать, что .gitattributesGitHub для Windows предлагает для вашего проекта? Я установил GitHub для Windows, запустил версию с графическим интерфейсом и не смог найти ни одной опции, связанной с .gitattributesпредложениями.
JLDiaz
4
Этот параметр не удовлетворит вас полностью, если в вашей команде есть люди, работающие с Egit, поскольку egit просто игнорирует .gitattributes и с радостью проверяет файлы CRLF bugs.eclipse.org/bugs/show_bug.cgi?id=342372
gatinueta
19
Для Windows я обычно склонен устанавливать глобальные core.autocrlf = false- я предпочитаю LF везде, но некоторые инструменты Windows, такие как Visual Studio, настаивают на окончаниях CRLF в определенных файлах (и даже смешивают их в нескольких ..); не жонглирование концов строк - самый безопасный вариант. Если вы знаете, что делаете, я бы, вероятно, использовал core.autocrlf = inputи сделал бы исключения для проектов в Windows, которые, как вы знаете, чувствительны к окончанию строк. Как отмечают другие, каждый приличный текстовый редактор теперь поддерживает LF-окончания. Я действительно думаю, что core.autocrlf = trueможет вызвать больше проблем, чем предотвратить.
Адриан
1
@gatinueta Чтобы быть более конкретным, это проблема JGit. Значение TeamCity, также использующее JGit, игнорирует .gitattributes.
ССРД ,
122

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

Джон Милликин
источник
25
Откомандирован. Если у вас есть проблемы с несовместимыми окончаниями строк, лучшее решение - кричать на тех, кто использует неправильные настройки редактора, пока они не исправят это.
136
Не согласен. Родные переводы строки на всех платформах - это удобство.
Йонас Быстрем
25
Visual Studio - это PITA, когда дело касается чего-либо, кроме CRLF.
Бретт Райан
32
Git имеет возможность не преобразовывать окончания строк, это autocrlf = false, и если вы не занимаетесь кроссплатформенной разработкой, как, например, Mono, лучше всего оставить false при работе под Windows и установить значение true, если вы будете разрабатывать с открытым исходным кодом. для моно.
Крис Никола
24
Проблема с окончанием строки - вычисление правильных различий. Так что ответ неверен и вводит в заблуждение.
потому что
84

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

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

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

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

Cory
источник
31
Почему это "правильная вещь"?
Артем Тихомиров
35
core.autocrlf = true - ужасная идея. У меня не было никаких проблем с этим параметром, плюс вы должны помнить, чтобы установить его всякий раз, когда вы клонируете хранилище.
Луис Оливейра
28
НЕ используйте autocrlf = true, если вы не знаете, что делаете. Если вы разрабатываете в DOS / Win, то autocrlf = false будет сохранять одинаковые окончания для удаленного и локального репо и является лучшим вариантом почти в любой ситуации.
Крис Никола
13
@Chris - Что, если у ваших разработчиков есть windows и мультиплатформенные проекты, в которых некоторые из мультиплатформенных разработчиков работают на OSX или Linux? Не должен ли лучший вариант быть autocrlf = true?
Бретт Райан
20
Утверждено, с оговорками. Вводный абзац бесполезен. core.autocrlf=inputэто канонический ответ. Для большинства случаев применения, core.autocrlf=trueи core.autocrlf=falseчрезмерно усердствовать (... в противоположном , но одинаково ужасных способах, конечно) и , следовательно , по своей природе разрушительный. «Git for Windows» действительно должен был поставляться с «Checkout как есть, фиксировать окончания строк в стиле Unix» (т.е. core.autocrlf=input) в качестве стратегии по умолчанию для новой строки. Это не так. Так что вот мы здесь - в офигенном 2015 году - до сих пор бесконечно обсуждаем это.
Сесил Карри
58

Две альтернативные стратегии для согласования окончаний строк в смешанных средах (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

lukmdo
источник
5
глобальный подход == установить и забыть для всех репо по сравнению с репо == не требует, чтобы другие изменили свою глобальную конфигурацию.
Lukmdo
4
dos2unixэто инструмент командной строки, который в зависимости от системы может потребоваться установить дополнительно
lukmdo
2
Они не являются эксклюзивными, вы можете использовать оба подхода одновременно. Кроме того, будьте очень осторожны при использовании dos2unix- есть риск повреждения,.git/index и нам не нужно применять его к каждому файлу. Лучше использовать что-то вроде find ./ -name "*.html"и указать, к каким файлам вы хотите применить это.
Cregox
6
ВНИМАНИЕ: перед запуском findстрок, имейте в виду: то, dos2unixчто поставляется с Git для Windows, имеет своеобразное (IMO идиотское и опасное) поведение без аргументов: вместо перехода на UNIX он переключает формат новой строки (DOS <-> UNIX )
leonbloy
2
И еще одно предупреждение: не DOS2UNIX вашей папке .git. Просто говорю.
Хакре
10

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

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

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

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

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

Грег Хьюгилл
источник
1
Не лучше ли использовать широкие настройки репозитория через файл .gitattributes? Было просто интересно: неудобно заставлять каждого пользователя заботиться о настройках окончания строки на своем компьютере ... Или есть другие недостатки?
trainoasis
10

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

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

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

Лэнс Кливленд
источник
31
@ orange80, несоответствие вызывает сожаление, но нет причин называть это виной Windows. LF-only имеет смысл с минималистской точки зрения, возможно; но CRLF имеет больше смысла, основываясь на том, что означают CR и LF. «Возврат каретки» означает возврат к началу строки; «перевод строки» означает переход прямо к следующей строке, а не к началу следующей строки. С семантической точки зрения Windows более правильна в том, чтобы и то и другое: вернуться назад в начало (CR), а затем вниз на одну строку (LF).
Райан Ланди
40
@Kyralessa «правильнее», все еще притворяясь, что компьютер - это пишущая машинка, но это не так. Поддерживать аналогию с пишущей машинкой не имеет никакого смысла, учитывая, что конечные пользователи никогда не будут иметь дело с этим, и что два символа вместо одного бессмысленны.
jpswain
1
Опоздал на эту вечеринку на несколько лет, но вы проигнорировали тот факт, что CR и LF являются инструментами позиционирования курсора. «CR» также может быть «возвращением курсора» на данном этапе истории. Если бы я хотел, чтобы курсор вернулся в начало строки, я бы сказал приложению сделать это. В противном случае он должен оставаться там, где я его положил.
EKW
2
Кроме того, если CRLF является «более правильным», поскольку новая строка текстового файла на самом деле является «перемещением на одну строку вниз» и «перемещением к началу строки», из этого следует, что только CR приведет к тому, что текстовый редактор перезапишет строку с следующая строка Я не знаю ни одного редактора, который бы на самом деле это поддерживал, а это означает, что необходимости выражать как CRLF, так и CR как разные вещи, на самом деле не существует.
avl_sweden
@avl_sweden Это было очень распространенное поведение до DOS, и, поскольку Microsoft считает, что совместимость важна, с тех пор она так и осталась. Это было также стандартным способом в США (как pere ASA) - ISO допускал как CR + LF, так и LF (так, опять же, DOS соответствовал стандартам); в обоих случаях, начиная с шестидесятых годов. Multics (предшественник Unix) поддерживает CR для жирного шрифта / удара. Многие приложения в настоящее время (в том числе .NET-функции "разбить по линиям") ищут любой из трех (одиночный CR, одиночный LF, CRLF) и рассматривают каждое из них как конечную строку. Тем не менее, многие приложения все еще смущены смешанными окончаниями строк в файле.
Луан
7

Это две опции для пользователей 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.
kiewic
источник
1
Ваша команда для пользователей Windows говорит git config --global core.autocrl true. Вы имеете в виду git config --global core.autocrlf true.
JellicleCat
6

--- ОБНОВЛЕНИЕ 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дезинфицирующие средства.

Маринос Ан
источник
Я согласен с вами, что это лучший подход, никто не должен использовать редакторы без поддержки LF. Но будьте осторожны с вашей .gitattributesлинией, он имеет непреднамеренный conseques в Git <2.10 см stackoverflow.com/a/29508751/2261442
ФГК
Черт возьми ... У меня есть тонны ответов, которые я защищаю git config --global core.autocrlf falseи рекомендую иметь дело с eol .gitattributesтолько в директивах.
VonC
5

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

В обычных случаях используйте решения, которые поставляются с 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
Джон Румпель
источник