У меня есть репозиторий Git, в котором есть файлы с форматом DOS (\r\n окончания строк). Я хотел бы просто запускать файлы с помощью dos2unix (что изменило бы все файлы в формате UNIX, с окончанием строки \n), но насколько это могло бы повлиять на историю, и рекомендуется ли это вообще?
Я предполагаю, что стандарт должен всегда использовать окончание строк UNIX для файлов с контролируемым источником и, возможно, локально локализовать контуры строк по умолчанию?
Подход, который вы будете использовать, зависит от того, насколько общедоступен ваш репозиторий.
Если вы не возражаете или не заботитесь об изменении всех SHA, потому что вы более или менее единственный, использующий его, но хотите, чтобы эта проблема была разобрана на все времена, вы можете запустить git filter-branch и применить dos2unix ко всем файлам в каждой фиксации. (Если вы используете репозиторий, все остальные нуждаются в более или менее полном обновлении, поэтому это потенциально опасно.)
Таким образом, лучший вариант, а также более простой способ - изменить его только в текущих головах. Это означает, что у вашего прошлого все еще есть окончания \r\n, но если вы не делаете много вишневого сбора из прошлого, это не должно быть проблемой. Разумеется, инструменты diff могут жаловаться немного чаще, но, как правило, вы просто разбираетесь с коммитами поблизости, поэтому этот вопрос решает сам по себе, поскольку коммиты накапливаются.
И окончание строк UNIX являются стандартными, вы правильно это знаете. Лучший подход заключается в том, чтобы настроить редактор только для написания этих окончаний даже в окнах. В противном случае существует также параметр 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
Эта crlf вела нас с ума, когда мы преобразовывали из svn в git (в центральной (голой), как) среде scm. То, что в конечном итоге привело нас, мы скопировали глобальный файл .gitconfig каждому пользователю root (да и оба окна и Linux), причем исходный из системы Windows и имеющий core.autocrlf = true и core.safecrlf = false, которые играли хаос на пользователей Linux (например, bash скрипты не работали и все эти ужасные ^ M). Итак, мы изначально сделали checkout и клонировали script, после чего команды dos2unix. Затем я наткнулся на элементы конфигурации core.autocrlf и core.safecrlf и установил их на основе O/S:
Windows: 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 script/usr/local/bin/gitfixcrlf:
#!/bin/sh
# remove local tree
git ls-files -z | xargs -0 rm
# checkout with proper crlf
git checkout .
Которые им нужно было запускать только на своих локальных клонах песочницы. Любое будущее клонирование было сделано правильно. Любые будущие толчки теперь обрабатываются правильно. Таким образом, это позволило решить многочисленные проблемы с O/S с помощью перевода строк. Также обратите внимание, что Mac находится в той же конфигурации, что и Linux.
Для дальнейшего решения взгляните на параметры core.autocrlf(и core.safecrlf) .
Выполнение этого один раз во весь ваш репозиторий приведет к созданию одного коммита, с которым невозможно смириться (поскольку каждая строка в этих файлах будет изменена), но как только вы пройдете мимо него, это не должно иметь большого значения. (Да, вы могли бы использовать git filter-branch, чтобы внести изменения в историю, но это немного страшно.)
Если ваш список файлов с контролируемыми версиями включает в себя двоичные файлы, или вы не можете легко изменить историю... вот удобный поддельный однострочный: