Git: новая пустая строка в EOF

Итак, я запускаю git diff --check перед add -инг файлами и commit -инг, а на двух конкретных файлах я получаю path/filename:linenumber: new blank line at EOF. Если я удалю последнюю пустую строку в этих файлах, я не получаю никаких сообщений, но я думаю, что это хороший стиль для завершения моих файлов с помощью новой строки. Как ни странно, другие файлы, которые, как я думаю, имеют точно такие же окончания, не дают никаких сообщений. Я новичок в git, используя git 2.0.1 на OS X Yosemite. Я использую vim в качестве моего редактора.

Как я могу закончить мои файлы с помощью новой строки, избегая этого сообщения? Должен ли я игнорировать его?

Ответ 1

Здесь есть две проблемы.

вы путаетесь о "новой строке" и "новой строке":

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

Большинство компиляторов, интерпретаторов и инструментов Unix ожидают, что ваши текстовые файлы заканчиваются символом новой строки, чтобы избежать двусмысленности при работе с несколькими файлами, а не "новой строкой".

В большинстве редакторов, включая Vim, добавьте необходимый символ в конце каждой строки, включая последнюю строку, поэтому вам нечего делать на вашей стороне, чтобы обеспечить выполнение этого требования.

Специально не добавляя "новую строку" в EOF.
вы, вероятно, привыкли к плохому поведению:

Символ "новой строки" традиционно интерпретируется как "ограничитель строки" инструментами Unix, большинством компиляторов и Vim. Это означает, что все, что приходит после этого символа, считается на другой линии. Поскольку этот символ является последним в файле, нет причин показывать строку, которая не существует для пользователя.

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

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

Либо вы продолжаете добавлять "новые строки" в нижней части исходных файлов, считайте это своего рода директиву форматирования и кодирования и перестаете рассматривать эти сообщения Git как сообщения об ошибках.

Или вы перестанете добавлять эти бесполезные "новые строки".

Я бы пошел со вторым вариантом.

Ответ 2

Из git diff документации:

- проверка

Предупреждать, если изменения вносят ошибки в пробелах. То, что считается ошибкой пробела, управляется конфигурацией core.whitespace. По умолчанию заглавные пробелы (включая строки, состоящие исключительно из пробелов) и пробельный символ, который сразу же следует за символом табуляции внутри начального отступа строки, считаются пробельными ошибками. Выходы с ненулевым статусом при обнаружении проблем. Не совместим с --exit-кодом.

Соответственно, git config документация:

core.whitespace

Список замеченных пробелов, разделенных запятыми. git diff будет использовать color.diff.whitespace, чтобы выделить их, а git apply --whitespace = error будет рассматривать их как ошибки. Вы можете префикс - отключить любую из них (например, -trailing-space):

blank-at-eol обрабатывает конечные пробелы в конце строки как ошибку (по умолчанию включена).

space-before-tab обрабатывает символ пробела, который появляется непосредственно перед символом табуляции в начальной части отступа строки как ошибка (включен по умолчанию).

indent-with-non-tab обрабатывает строку с отступом с символами пробела вместо эквивалентных вкладок в качестве ошибки (она не включена по умолчанию).

tab-in-indent обрабатывает символ табуляции в начальной части отступа строки как ошибку (не включен по умолчанию).

blank-at-eof обрабатывает пустые строки, добавленные в конце файла, в качестве ошибки (включен по умолчанию).

trailing-space является короткой рукой для покрытия как blank-at-eol, так и blank-at-eof.

cr-at-eol обрабатывает возврат каретки в конце строки как часть терминатора строки, т.е. с ним, конечное пространство не запускается, если символ перед таким возвратом каретки не является пробелом ( не включен по умолчанию).

tabwidth=<n> указывает, сколько позиций символов занимает вкладка; это имеет значение для indent-with-non-tab и когда git исправляет ошибки "вставить". Ширина закладки по умолчанию - 8. Разрешенные значения: от 1 до 63.

Как вы можете видеть, blank-at-eof включен по умолчанию. Вы можете отключить его, добавив -blank-at-eof в конфигурацию core.whitespace или, альтернативно, используя собственную конфигурацию core.whitespace.