Что означает «1 строка добавляет ошибки пробелов» при применении патча?

Я редактирую некоторые файлы уценки клонированного удаленного репозитория и хотел протестировать создание и применение исправлений из одной ветки в другую. Однако каждый раз, когда я вообще вношу какие-либо изменения, я получаю следующее сообщение git apply:

0001-b.patch:16: trailing whitespace.
warning: 1 line adds whitespace errors.

(Это происходит на моем Mac, и я не знаю, где был создан исходный код.)

Что означает предупреждающее сообщение и нужно ли мне беспокоиться?

Тебе не нужно заботиться.

Предупреждение вводит стандарт чистоты текстовых файлов в отношении пробелов, о чем обычно заботятся многие программисты. Как объясняется в руководстве :

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

По умолчанию команда выводит предупреждающие сообщения, но применяет исправление.

Итак, «ошибка» означает, что изменение вводит завершающий пробел, строку, состоящую только из пробелов, или пробел, который предшествует табуляции. Кроме этого факта, в изменении нет ничего ошибочного, и оно будет применяться чисто и правильно. Другими словами, если вас не волнуют «неправильные» пробелы, не обращайте внимания на предупреждение или отключите его с помощью git config apply.whitespace nowarn.

Один из случаев, когда вы могли бы на законных основаниях проявлять осторожность, - это когда вы хотите различать «старую» ошибку пробелов (которую вы, возможно, захотите сохранить по устаревшим причинам) и «новые» ошибки пробелов (которых вы хотите избежать).

С этой целью Git 2.5+ (второй квартал 2015 г.) предложит более конкретную опцию для обнаружения пробелов.

См. Коммиты 0e383e1 , 0ad782f и d55ef3e [26 мая 2015 г.], автор - Junio ​​C Hamano ( gitster) .
^{(Объединено Junio в коммите 709cd91 , 11 июня 2015 г.)}

diff.c: --ws-error-highlight=<kind>option

Традиционно нас заботили только пробелы, появляющиеся в новых строках.
Некоторые люди хотят рисовать пробелы и на старых строках. Когда они видят обрыв пробелов в новой строке, они могут заметить такие же обрывы пробелов в соответствующей старой строке и хотят сказать: «А, эти обрывы есть, но они унаследованы от оригинала, поэтому давайте не будем их трогать. сейчас."

Представьте --ws-error-highlight=<kind>вариант, что позволяет им пройти через запятую список old, newи contextуказать , какие строки выделить пробелы ошибки на.

Документация в настоящее время включает в себя :

--ws-error-highlight=<kind>

Выделите ошибки пробелов в строках, указанных с <kind>помощью цвета, указанного с помощью color.diff.whitespace.
<kind>это разделенный запятыми список old, new, context.
Если этот параметр не задан, вnew строках.

Например, --ws-error-highlight=new,oldвыделяет ошибки пробелов как в удаленных, так и в добавленных строках.
allможет использоваться как сокращение для old,new,context.

Например, у старой фиксации была одна ошибка пробела ( bbb), но вы можете сосредоточиться только на новых ошибках (в конце still bbbи ccc):

(тест сделан после t/t4015-diff-whitespace.sh)

В Git 2.26 (Q1 2020) diff-*семейство подкоманд сантехники теперь обращает внимание на diff.wsErrorHighlightконфигурацию, которая раньше игнорировалась; это позволяет " git add -p" также показывать конечному пользователю проблемы с пробелами.

См. Commit da80635 (31 января 2020 г.) Джефф Кинг ( peff) .
^{(Объединено Junio ​​C Hamano - gitster- в коммите df04a31 , 14 февраля 2020 г.)}

diff: переместить diff.wsErrorHighlight в "базовую" конфигурацию

^{Подписано: Джефф Кинг}

Мы разбираем diff.wsErrorHighlight в git_diff_ui_config(), что означает, что он не действует для команд сантехники, только для таких фарфоров, как он git diffсам.
Это слегка раздражает, так как это означает add--interactive, что такие сценарии , которые создают видимую пользователю разницу с цветом, не соблюдают этот параметр .

Мы могли бы научить этот сценарий анализировать конфигурацию и передавать ее --ws-error-highlightв систему различий. Но есть более простое решение.

Для сантехников должно быть достаточно безопасно соблюдать этот параметр, поскольку он срабатывает только тогда, когда в противном случае включен цвет. И любой, кто разбирает раскрашенный вывод, должен уже иметь дело с тем фактом, что color.diff.*может изменить точный вывод, который они видят; эти параметры были частью git_diff_basic_config()с момента его появления в 9a1805a872 (добавить "базовый" обратный вызов конфигурации diff, 2008-01-04, Git v1.5.4-rc3).

Таким образом, мы можем просто переместить его в «базовую» конфигурацию, которая исправляет add--interactive, наряду с любым другим скриптом в той же лодке, с очень низким риском причинения вреда пользователям сантехники.

Здесь показана ошибка пробелов с визуальными изображениями.

http://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#Commit-Guidelines

Поскольку строка TABначинается с istead of SPACE. Перейдите к файлу патча и замените его TABна SPACE. Например, на vim в строке + из файла патча введите x, чтобы удалить пробел, а не удалить знак + и вставить пробел (CTRL) в eqiv до исходного размера.