Это не совсем верно, но достаточно близко: проблема здесь в том, что Git имеет то, что составляет направленное преобразование . Документация Git не говорит о своих преобразованиях таким образом, но, возможно, так и должно быть.
Может быть полезно думать о файлах, хранящихся в Git, как о «формате Git»: сжатых и, если вы определите clean filter через .gitattributes и вашу конфигурацию, cleaned . Даже если вы не определите конкретный чистый фильтр, если вы настроите преобразования CRLF, Git выполнит здесь некоторую очистку: файлы, хранящиеся в хранилище, будут только для LF. Ожидается, что файлы в вашем рабочем дереве, как вы почти сказали, будут в вашем предпочтительном рабочем формате: не Git-сжатые, с использованием окончаний CRLF , если вы их выбрали, и нечеткое изображение через ваш грязный фильтр , если вы установите один из них (аналогично настройке чистого фильтра).
Это действительно в основном для пользователей Windows, где редакторы и среды Windows имеют своего рода предпочтение для концов строк CRLF. Когда все настроено правильно, рабочие копии файлов, которые используются при работе, имеют окончания CRLF так, как этого хочет Windows, и зафиксированные копии файлов, которые можно использовать только путем извлечения их в рабочие копии, имеют LF- только окончания, как их предпочитает Linux.
Эти преобразования фактически выполняются в то время, когда файлы перемещаются из index - промежуточной структуры, которую Git налагает между коммитами и рабочими деревьями - в рабочее дерево или из рабочего дерева в индекс. Git делает коммиты из того, что находится в индексе, поэтому, «чистя» файлы на пути от рабочего дерева к индексу, Git может зафиксировать чистые версии, а путем уничтожения файлов на пути от индекса к рабочему дереву Git может обеспечить грязные окончания CRLF, которые нравятся Windows.
Мы можем включить или выключить этот тип преобразования. Когда он все выключен полностью выключен, Git не беспокоится о проверке чего-либо, так что файлы в индексе являются просто просто сжатыми версиями файлов в рабочее дерево и файлы в рабочем дереве - это просто несжатые версии того, что находится в индексе (конечно, пока вы сами не измените версию рабочего дерева). В этом случае вы можете получить окончания CRLF в хранилище. Похоже, именно это произошло с вашим конкретным хранилищем.
Самый простой подход к решению этой проблемы в любой системе, где CRLF не вредит удобству использования (а это большинство систем), - просто оставить его. Следующий простейший способ - исправить это в репо , но, как вы сказали, для этого требуется контроль над хранилищем.
Если какой-то конкретный файл доставляет вам проблемы из-за его окончаний CRLF, в Git нет ничего встроенного, что переведет его на LF-only в вашем рабочем дереве, затем вернитесь к CRLF, когда вы git add получите результат. Тем не менее, вы можете установить свои собственные пятна и чистые фильтры, которые делают именно это: установите фильтр пятна очистите файл (превратив CRLF в LF-only), и установите фильтр очистки грязным файл (путем преобразования LF-only в CRLF). Затем вы можете настроить файл .gitattributes или .git/info/attributes на , используя эти фильтры для определенных файлов. См. документацию gitattributes для более подробной информации, но по существу:
badfile1.ext filter=reverse-clean
badfile2.xtn filter=reverse-clean
вместе с:
[filter "reverse-clean"]
clean = sed -e $'s/\\r*$/\\r/'
smudge = sed -e $'s/\\r$//'
(теперь тестируется как драйвер фильтра Git - в приведенном выше примере предполагается, что команда подается на sh -c, а sh интерпретирует $'...'; двойная обратная косая черта связана с тем, что это входит в файл конфигурации).
Как вы заметили в комментарии ниже, есть небольшое раздражение: git diff показывает возврат каретки на измененных строках, но не на окружающих строках, что делает различия немного уродливыми. Это, кажется, работает как хотелось бы.