Гит:Удаление возврата каретки из файлов с контролем источника

Question

У меня есть репозиторий Git, в котором есть файлы в формате DOS (\r\n окончания строк).Я хотел бы просто запустить файлы через dos2unix (что приведет к изменению всех файлов в формат UNIX, с \n окончания строк), но насколько сильно это повлияет на историю и рекомендуется ли вообще?

Я предполагаю, что стандартом является всегда использовать окончания строк UNIX для файлов, управляемых исходным кодом, и, при необходимости, локально переключаться на окончания строк, специфичные для ОС?

Answer 1

Подход, который вам придется использовать, зависит от того, насколько общедоступен ваш репозиторий.

Если вы не возражаете или не хотите изменить все SHA, потому что вы более или менее единственный, кто его использует, но хотите, чтобы эта проблема была решена навсегда, вы можете запустить git filter-branch и применить dos2unix ко всем файлам в каждом коммите.(Если вы используете общий репозиторий, всем остальным потребуется более или менее полностью его обновить, поэтому это потенциально опасно.)

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

Окончания строк UNIX являются стандартными, в этом вы правы.Лучший подход — настроить ваш редактор так, чтобы он писал только эти окончания даже в Windows.В противном случае также существует autocrlf настройки, которые вы можете использовать.

---

Дополнение к части переписывания истории:

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

#!/bin/bash
all2dos() { find * -exec dos2unix {} \; }
export -f all2dos
git filter-branch -f --tree-filter 'all2dos' --tag-name-filter cat --prune-empty -- --all

Answer 2

Эта штука с crlf сводила нас с ума, когда мы конвертировали из svn в git (в центральной (пустой) среде scm.В конечном итоге нас поразило то, что мы скопировали глобальный файл .gitconfig в корень каждого пользователя (да, как в Windows, так и в Linux), причем первоначальный файл был взят из системы Windows и имел core.autocrlf=true и core.safecrlf=false, что привело к хаосу. для пользователей Linux (например, не работали сценарии bash и все эти ужасные ^M).Итак, сначала мы создали сценарий извлечения и клонирования, который выполнял dos2unix после этих команд.Затем я наткнулся на элементы конфигурации core.autocrlf и core.safecrlf и установил их в зависимости от операционной системы:

Окна:core.autocrlf = true и core.safecrlf = false linux:core.autocrlf=input и core.safecrlf=false

Они были установлены с:---в Windows---

git config --global core.autocrlf true
git config --global core.safecrlf false

---в Linux---

git config --global core.autocrlf input
git config --global core.safecrlf false

Затем для наших разработчиков Linux мы настраиваем небольшой bash-скрипт /usr/local/bin/gitfixcrlf:

#!/bin/sh
# remove local tree
git ls-files -z | xargs -0 rm
# checkout with proper crlf
git checkout .

Который им пришлось запустить на своих локальных клонах песочницы только один раз.Любое будущее клонирование было выполнено правильно.Любые будущие толчки теперь обрабатывались правильно.Итак, это решило наши многочисленные проблемы операционной системы с переводом строки.Также обратите внимание, что Mac имеет ту же конфигурацию, что и Linux.

Answer 3

Для дальнейшего решения взгляните на core.autocrlf (и core.safecrlf). параметры конфигурации.

Если вы сделаете это один раз для всего вашего репозитория, вы просто создадите один коммит, с которым практически невозможно объединиться (поскольку каждая строка в этих файлах будет изменена), но как только вы его преодолеете, это не составит большого труда.(Да, вы можете использовать git filter-branch вносить изменения на протяжении всей истории, но это немного пугает.)

Answer 4

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

https://unix.stackexchange.com/a/365679/112190