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

Question

У меня есть машина Windows с проектом VS, и я использую и 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 добавили его в теги (в Stackru нет тега для core.safecrlf)
• git версия 1.8.5.rc1.17.g0ecd94d (скомпилировано из исходников под Cygwin)

РЕДАКТИРОВАТЬ #1: проверено core.autocrlf - это было input, Изменился на falseТеперь я могу добавить оба файла. Зачем?

Answer 1

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

FWIW core.autocrlf = input является предпочтительным параметром в системах Unix и используется по умолчанию cygwin build, вероятно, установить это так. В 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 в input в Windows, если все редакторы Windows и другие инструменты обработки текстовых файлов в проекте знают конец строки Unix, в противном случае установите для него значение core.autocrlf = true для Windows и core.autocrlf = input для Unix. В любом случае этот подход устарел из-за превосходного метода .gitattributes файл.

.gitattributes Метод file обрабатывает файлы на основе имени файла и поддерживается во всех пользовательских средах, поскольку он извлекается в рабочий каталог, например .gitignore, Настройки для такого количества имен и типов файлов, которые имеют отношение к вашему проекту, должны быть добавлены в .gitattributes, Затем ваша конфигурация возвращается к локальным настройкам core.autocrlf и core.safecrlf, если имя файла не совпадает в .gitattributes, Добавление * text=auto на вершине .gitattributes вызовет git сделать лучший выбор по именам файлов, которые не соответствуют последним .gitattributes Настройки.

Эта веб-страница " Mind the End of Your Line" помогла мне лучше понять проблему. Вы можете прочитать дополнительную информацию по этому вопросу.

Answer 2

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

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

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