Що означає "1 рядок додає помилки пробілів", коли застосовується патч?


105

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

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

(Це відбувається на моєму Mac, і я не знаю, де був створений оригінальний код.)

Що означає попереджувальне повідомлення, і чи потрібно мені піклуватися?


Відповіді:


126

Вам не потрібно дбати.

Попередження передбачає стандарт чистоти текстових файлів щодо місця пробілів, те, про що багато програмістів дбають. Як пояснює посібник :

Що вважається помилками пробілу, контролюється конфігурація core.whitespace. За замовчуванням пробіли пробілів (включаючи рядки, що складаються виключно з пробілів) та символ пробілу, за яким відразу слідує символ вкладки всередині початкового відступу рядка, вважаються помилками пробілів.

За замовчуванням команда виводить попереджувальні повідомлення, але застосовує патч.

Отже, "помилка" означає, що зміна вводить пробіл пробілу, лінію, що містить лише пробіл, або пробіл, який передує вкладці. Крім цього факту, в зміні немає нічого помилкового, і воно буде застосовуватися чисто і правильно. Іншими словами, якщо вам не байдуже про "неправильне" пробіл, сміливо ігноруйте попередження або вимкніть його git config apply.whitespace nowarn.


12
Подивіться на поступку git show- якщо ваш git зробить кольори, ви побачите, як кривдні пробіли підійдуть у сердито-червоному. Також git show --word-diffпокаже вам не тільки зміну рядка, але і вставки в середині рядка, які повинні показувати, чи патч дійсно лише додає слово посередині, чи він також додає пробіл пробілу.
user4815162342

12
Вам не потрібно дбати. Але ви повинні. Сліди пробілів повинні бути ліквідовані.
funroll

1
За винятком випадків, коли OP не додає нового пробілу, а лише модифікує те, що вже існує.
user4815162342

4
Я бачив цю підтримку в подібній ситуації, коли закінчення рядків - це CRLFs стилю Windows, а не Unix.
Ezequiel Muns

1
@Yarin Якщо ви додасте слово в середині рядка, а в рядку вже є пробіл пробілу, це може викликати попередження.
Warren Dew

4

Один з випадків, коли ви могли б законно піклуватися, це коли ви хочете розмежовувати "стару" помилку пробілу (яку ви можете зберегти з застарілої причини) та "нову" помилки пробілу (яких ви хочете уникнути).

Для цього Git 2.5+ (Q2 2015) запропонує більш конкретний варіант для виявлення пробілів.

Див. Коміти 0e383e1 , 0ad782f та d55ef3e [26 травня 2015] від Junio ​​C Hamano ( gitster) .
(Злити Junio в фіксації 709cd91 , 11 Червня 2015)

diff.c: --ws-error-highlight=<kind>варіант

Традиційно ми дбали лише про поломки білого простору, запроваджені в нових рядках.
Деякі люди також хочуть намалювати поломки білого простору на старих лініях. Коли вони бачать розрив білого простору на новій лінії, вони можуть помітити такий самий вид розриву пробілу на відповідній старій лінії і хочуть сказати "Ах, ці поломки є, але вони були успадковані від оригіналу, тому не будемо торкатися їх до зараз ".

Введіть --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):

старі та нові помилки у просторі shitespace

(тест зроблено після t/t4015-diff-whitespace.sh)


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

Див. Команду da80635 (31 січня 2020 р.) Джеффа Кінга ( peff) .
(Об’єднав Хуніо С Хамано - 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 (додайте "базовий" розрив call config, 2008-01-04, Git v1.5.4-rc3).

Таким чином, ми можемо просто перемістити його до "базового" конфігурації, який виправляє add--interactiveразом з будь-яким іншим сценарієм у тому ж човні з дуже низьким ризиком пошкодити будь-яких користувачів сантехніки.



-2

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


1
-1 Ви справді думаєте, що Git скаржиться на відступ вкладки стилю Linus? Єдине легальне використання вкладки, якщо така є, - це саме початок рядка.
user2394284
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.