Как восстановить CRLF в репозитории GIT, чтобы избежать конфликтов слияния

Я создал свой репозиторий с помощью autocrlf=true, а затем сделал несколько проверок и коммитов с помощью autocrlf=false. Затем переключился обратно на autocrlf=true (ОС Win). Все вроде бы было ок, пока я не начал слияние между ветками. Возникало много конфликтов слияния, когда весь файл помечался как измененный из-за измененного eols (я полагаю, это были те файлы, которые были извлечены и зафиксированы с autocrlf=false).

Есть некоторая история, которая для меня стоит, поэтому я предпочитаю сделать некоторое преобразование или исправить коммиты с преобразованным eols, а не создавать новое репо и начинать новую жизнь.

Вот как я понимаю autocrlf (ОС Win):

случай если autocrlf=true

WorkingTree ->  commit  -> GITRepository
CRLF         CRLF to LF      LF
LF           no conv.        LF
WorkingTree <- checkout <- GITRepository
CRLF         LF to CRLF      LF

случай если autocrlf=false

WorkingTree ->  commit  -> GITRepository
CRLF         no conv.      CRLF
LF           no conv.      LF
WorkingTree <- checkout <- GITRepository
CRLF         no conv.      CRLF
LF           no conv.      LF

Теперь я хотел бы использовать GIT с autocrlf=false, поэтому я решил проверить каждую ветку, восстановить eols исходных файлов с помощью утилиты Конвертер EOL и зафиксируйте его с помощью CRLF. Я это сделал, но по прошествии времени остались некоторые файлы, которые, вероятно, не были проверены после того, как я изменил настройку autocrlf на false (или эти файлы объединились из старых неисправленных коммитов? При конвертации я использовал маску *.filetype для автоматизировать обработку всех LF в CRLF, поэтому для меня нет другого объяснения такой ситуации). Я также пытался touch файлы, чтобы повторно зафиксировать их все (как я видел где-то здесь в stackoverflow), но изменение даты не имеет отношения к GIT AFAIK. Я также читал Как устранить ущерб, нанесенный autocrlf, но не уверен, что это мой случай, а также не понимаю фокусов волшебника.

Как я могу избавиться от этого беспорядка, пожалуйста?


person Andik    schedule 25.08.2011    source источник
comment
ты пробовал autocrlf=input? если ваше репо не было общедоступным, вы можете использовать это и filter-branch --index-filter для очистки окончаний строк в своей истории.   -  person knittl    schedule 26.08.2011
comment
@knittl: Насколько я понимаю, это перезапишет все коммиты в истории с помощью LF. Я прав? Тогда мне, вероятно, придется повернуть autocrlf=true, чтобы получить CRLF после оформления заказа (OS Win). Есть ли возможность преобразовать репо напрямую в CRLF и оставить после этого autocrlf=false?   -  person Andik    schedule 30.08.2011
comment
как только репозиторий будет преобразован в CRLF, вы сможете иметь autocrlf=false, поэтому окончания строк не преобразуются и остаются такими, как они есть в файле.   -  person knittl    schedule 30.08.2011
comment
@knittl: Таким образом, установка autocrlf=input вызывает конверсию во время фиксации и отсутствие конверсии во время проверки. Что именно происходит на компьютере с Windows? Репозиторий будет полностью CRLF или весь LF? Я не могу найти это в руководстве. Спасибо.   -  person Andik    schedule 31.08.2011
comment
из справочной страницы git config: »Это переменной может быть присвоено значение input, и в этом случае преобразование вывода не выполняется.«   -  person knittl    schedule 31.08.2011
comment
@knittl: я понимаю, но какое преобразование ввода будет выполнено? Хорошо, я попробую на каком-нибудь тестовом репо, спасибо.   -  person Andik    schedule 31.08.2011
comment
входное преобразование должно быть CRLF→LF   -  person knittl    schedule 31.08.2011
comment
@knittl: Привет еще раз, я пытался использовать эту команду, но она не завершена, что должно следовать после filter-branch --index-filter ? Спасибо.   -  person Andik    schedule 13.09.2011
comment
andik: попробуй git filter-branch --tree-filter 'true;' --all. Я думаю, вам понадобится древовидный фильтр вместо индексного фильтра, потому что преобразование crlf происходит только при оформлении заказа (другими словами: вам нужно рабочее дерево). 'true;' здесь просто фиктивный фильтр, который на самом деле ничего не делает   -  person knittl    schedule 13.09.2011


Ответы (2)


Используйте параметр git merge «игнорировать изменение пробела» или «игнорировать все пространство» для «рекурсивной» стратегии. Эта опция есть по крайней мере в 1.7.4.1.

person e40    schedule 22.09.2011

Простой ответ: если вы НЕ делаете x-платформенную разработку с не-Windows, установите для этого параметра значение false. Нет необходимости в том, чтобы система управления версиями искажала ваши файлы за вас. После устранения всех оставшихся проблем вы должны летать. Убедитесь, что другие, работающие с вами, также установили для этого параметра значение false.

person Adam Dymitruk    schedule 29.12.2011
comment
Я предлагаю, чтобы эта опция ВСЕГДА была установлена ​​в значение true для Windows — вы столкнетесь с множеством проблем с другими платформами, если на самом деле этого не сделаете. - person David Losert; 18.03.2015