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

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

дополнительная информация ниже:

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

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

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

А. Глобальные для всех репозиториев Setup

1) преобразование все в один формат

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

2) установить core.autocrlf to input в Linux / UNIX или true на MS Windowns (репозиторий или глобальный)

git config --global core.autocrlf input

3) [ опционально ] набор core.safecrlf to 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'

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

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

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

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

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

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

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

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

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

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

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

* text=auto

в вашем РЕПО добавить:

*   text=auto

это нормализует все файлы с помощью LF окончание строки в репо.

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

это конфигурация, которая Microsoft .NET использование РЕПО.

пример:

Hello\r\nWorld

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

Hello\nWorld

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

Hello\r\nWorld

при оформлении заказа, рабочее дерево в Mac будет оставлен как:

Hello\nWorld

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

ядра.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.

это просто решение устранение:

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

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

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

мое решение:

ОС Windows-Машинам: Пусть все как есть. Не заботьтесь ни о чем, так как вы являетесь разработчиком windows lone wolf по умолчанию, и вам нужно обращаться так: "нет другой системы в широком мире, это это?"

Unix-Машины

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

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

2. преобразовать все эти изменить файлы в формате dos:

   unix2dos $(git lc)
   

3. дополнительно ...

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

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

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

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

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

      ... и огонь преобразованные вещи, введя

      git c2dos
      

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

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

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

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

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

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

--- обновление ---

даже если вы не хотите использовать выше стратегия,следующая команда - ваш друг (Примечание: на клиентах Windows работает только через git-bash и на клиентах Linux только при компиляции с использованием --with-libpcre на ./configure).

# Print all files that have been committed with CRLF (more correctly that contain CR), so that you normalize them.
git grep -I --files-with-matches --perl-regexp '\r' HEAD

один болезненный пример:

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

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