Я создал свое репо с autocrlf=true, а затем сделал несколько проверок и совершил транзакцию с autocrlf=false. Затем переключитесь на autocrlf=true (OS Win).
Все казалось ОК, пока я не начал слияния между ветвями. Многие конфликты слияния возникли, когда весь файл был отмечен как измененный из-за изменения eols (я полагаю, это были те файлы, которые были извлечены и отправлены с помощью autocrlf=false).
Существует некоторая история, которая стоит для меня, поэтому я предпочитаю совершать некоторые преобразования или фиксации с преобразованным eols, а не создавать новое репо и начинать новую жизнь.
Вот как я понимаю autocrlf (OS 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, но не уверен, что это мой случай, а также не понимаю трюки мастера.
Как я могу уйти от этого беспорядка, пожалуйста?