Пытаясь зафиксировать файлы Git, но получив:: fatal: LF будет заменен CRLF в <some file in repo>

Когда я пытаюсь зафиксировать некоторые измененные файлы, я получаю следующее сообщение об ошибке с TortoiseGit

fatal: LF would be replaced by CRLF in <some file in the repo>

Теперь, прежде чем я получу обычные ответы LF vs CRLF, я знаю и понимаю, о чем идет дискуссия. Во-вторых, я также установил свои глобальные настройки:

core.autocrlf true

В-третьих, У меня есть файл .gitattributes.

Итак, я хочу, чтобы убедиться, что файлы или файлы вынуждены иметь CRLF.

Я не понимаю, что он говорит FATAL и блокирует меня от продолжения. Предупреждение? Конечно! Знаю ли я, что я пытаюсь сделать? Я делаю!

Я просто хочу, чтобы он конвертировался молча и STFU.

В качестве альтернативы, если он принудительно блокирует меня, есть ли способ, чтобы я мог обновлять все файлы в репо, чтобы быть CRLF, поэтому это предупреждение может потеряться?

Эти репо являются частными, поэтому они никогда не будут разработаны за пределами Windows + Visual Studio.

Может ли кто-нибудь помочь, не опуская эту нить в религиозную войну autocrlf TRUE vs autocrlf FALSE.

ОТВЕТЫ

Ответ 1

Возможно, вы захотите установить core.safecrlf на "предупреждение", если вы хотите только предупреждение, а не фатальную ошибку.

От "git config" страница mange:

core.safecrlf

Если true, делает git проверяет, является ли преобразование CRLF обратимым, когда включено преобразование конца строки. git будет проверять, будет ли команда изменять файл в дереве работы прямо или косвенно.
Например, запись файла с последующей проверкой того же файла должна привести к исходному файлу в дереве работ. Если это не так для текущей настройки core.autocrlf, git отклонит файл.
Переменная может быть установлена ​​на "warn", и в этом случае git будет предупреждать только о необратимом преобразовании, но продолжить операцию.

Преобразование CRLF имеет небольшую вероятность развращения данных.
Когда он включен, git преобразует CRLF в LF во время фиксации и LF в CRLF во время проверки.
Файл, содержащий смесь LF и CRLF до фиксации, не может быть восстановлен с помощью git.
Для текстовых файлов это правильная вещь: она исправляет концы строк таким образом, что в репозитории есть только концы строк LF.
Но для двоичных файлов, которые случайно классифицируются как текст, преобразование может испортить данные.

Если вы распознаете такое повреждение раньше, вы можете легко исправить его, указав тип преобразования явно в .gitattributes.
Сразу после фиксации у вас все еще есть исходный файл в дереве вашей работы, и этот файл еще не поврежден. Вы можете явно указать git, что этот файл является двоичным, а git будет обрабатывать файл соответствующим образом.

К сожалению, желаемого эффекта очистки текстовых файлов со смешанными окончаниями строк и нежелательного эффекта развращения двоичных файлов нельзя отличить. В обоих случаях CRLF удаляются необратимым образом. Для текстовых файлов это правильная вещь, потому что CRLF - это окончания строк, тогда как для двоичных файлов конвертирование CRLF развращает данные.

Я предпочитаю идентифицировать точные файлы или типы файлов, которые я хочу заставить eol только с .gitattributes файлами (с настройками core.eol, которые у вас есть), и оставьте autocrlf на false.

В случае текстовых сообщений с смешанным eol этот пост в блоге предлагает, например,:

Если у вас установлен Notepad ++ на вашем компьютере, просто выполните следующие действия.

  • Откройте файл с фатальной проблемой.
  • Нажмите Edit -> EOL Conversion, затем выберите формат Windows или любой из них, у вас возникла проблема.

Ответ 2

git config --global core.safecrlf false

Ответ 3

Это отключит аварийное предупреждение crlf.

git config core.autocrlf false
git config core.safecrlf false

Ответ 4

git config --global core.autocrlf false будет проверять файлы с CRLF, которые не используются.

Я заметил в Windows, что с core.autocrlf true git не нравится файлы с LF, а core.autocrlf input не нравится CRLF.

Итак: зафиксируйте файлы CRLF с core.autocrlf true и LF файлами с помощью core.autocrlf input (или преобразуйте их в CRLF).

Обычно файлы с LF автоматически генерируются генераторами кода (например, https://start.spring.io или http://yeoman.io/)