Я создал свой репо с 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 converter и зафиксировать обратно с помощью CRLF. Я сделал это, но через некоторое время все еще есть некоторые файлы, которые, вероятно, не были извлечены после того, как я изменил настройку autocrlf на false (или эти файлы стали объединяться из более старых нефиксированных коммитов? Во время преобразования я использовал маску * .filetype для автоматизации обработки всех LF в CRLF, поэтому для меня нет другого объяснения такой ситуации).
Я также попытался touch файлов, повторно зафиксировать их все (как я видел где-то здесь в stackoverflow), но изменение даты не имеет отношения к GIT AFAIK. Я также прочитал Как отменить повреждение autocrlf , но не уверен, что это мой случай, а также не понимаю хитрости волшебника.
Как мне избежать этого беспорядка, пожалуйста?