Git core.safecrlf различное поведение в файлах с одинаковыми окончаниями строк

у меня есть машина Windows с VS project, и я использую как Visual Studio, так и инструменты из среды Cygwin, включая Git. Иногда я получаю разные окончания строк в файлах после редактирования. Я хочу, чтобы простое решение проверяло согласованность строк файлов, прежде чем они перейдут в репо. В Git core.safecrlf это правильная вещь, я полагаю. Теперь у меня странное поведение:

файлы A и B со следующими параметрами:

$file A
A: HTML document, UTF-8 Unicode text, with CRLF line terminators
$file B
B: HTML document, UTF-8 Unicode (with BOM) text, with CRLF line terminators

файл A уже находится в репо, файл B это новый. Обратите внимание, что оба имеют окончания строк CRLF. Теперь попробуй поставить их,core.safecrlf и true.

$git add A  # ok
$git add B  # fails
fatal: CRLF would be replaced by LF in B.

С core.safecrlf правильно? Или, может быть, мне нужно написать крюк, чтобы проверить файлы?

Примечания:

  • пробовал с разными кодировками файлов (с и без спецификации), без разницы.
  • есть связанные core.autocrlf функция в Git, добавила его в теги (Stackoverflow не имеет тега для core.safecrlf)
  • git версия 1.8.5.ник1.17.g0ecd94d (скомпилировано из источников под Cygwin)

EDIT #1: проверено core.autocrlf - это input. Изменено на false, теперь я могу добавлять файлы. Почему?

9
core.autocrlf cygwin git newline windows

2 ответов

согласно вашему более позднему редактированию core.autocrlf = input была первоначальная настройка. С этой настройкой CRLF превращается в LF при регистрации в репозитории и так и держится когда проверили. Это означает, что редактор без Unix-строк, такой как Notepad, испортит внешний вид проверенной версии файла. Это будет одна гигантская длинная очередь.

чистки рядов core.autocrlf = input является предпочтительным параметром в системах Unix и использует значение по умолчанию cygwin построить, наверное пусть будет так. В Windows рекомендуемыми настройками являются core.autocrlf = true что msysgit рекомендует

core.safecrlf = true прерывает преобразование файла, если проверка файла приведет к изменению и, возможно, поврежденному файлу, который будет иметь место, если Notepad был редактором. Вот почему файл B был прерван, потому что он был бы перепутан в Редакторе, таком как блокнот. Разница между core.SAFEcrlf и core.AUTOcrlf следует отметить. Это один из eyes glazing over проблемы в понимании git окончание строки

core.autocrlf = false это не волнует режим. Он будет проверять и проверять файлы точно так, как они есть, поэтому коммиты теперь работают. Это не очень умно и не рекомендуется, потому что это вызывает проблемы, если файлы редактируются в системах Windows и Unix, а также если другие пользователи core.autocrlf настройки отличаются и изменяют окончания файлов.

мое собственное предпочтение-установить core.autocrlf to input на Windows, если все Редакторы Windows и другие инструменты обработки текстовых файлов в проекте-Unix line ending aware, в противном случае установите его в core.autocrlf = true для Windows и core.autocrlf = input для Unix. В любом случае этот подход устарел благодаря превосходному методу

28

выбор окончания линии CR LF не так легко понять. Есть два места для описаний в том, что он охвачен как в руководствах Git-attributes, так и в руководствах git-config.

первоначально были настройки autocrlf, а затем появились новые версии, которые имеют некоторые потенциальные несовместимости (т. е. делают неожиданные вещи, как вы указываете).

Я склонен устанавливать eol=LF, что делает все текстовые файлы фиксированными как окончания строк LF (вы можете установить атрибуты о том, какие файлы считаются текстовыми), а затем добавьте safecrlf для проверки туда и обратно.

2