git add --interactive “Ваш відредагований шматок не застосовується”

Я намагаюся git add --interactiveвибірково додати деякі зміни до свого індексу, але постійно отримую повідомлення "Ваш відредагований шматок не застосовується. Редагувати ще раз ...". Я отримую це повідомлення, навіть якщо вибираю опцію e, і негайно зберігаю / закриваю свій редактор. Іншими словами, без жодного редагування куска, патч не застосовується.

Ось точний приклад, який я використовую (я намагаюся скласти невеличку демонстрацію):

Оригінальний файл:

first change
second change off branch
third change off branch
second change
third change
fourth change

Новий файл:

Change supporting feature 1
first change
second change off branch
third change off branch
second change
third change
fourth change
bug fix 1
change supporting feature 1

Я намагаюся показати, як використовувати git add --interactiveдля додавання до індексу лише рядок "виправлення помилок 1". Запускаючи інтерактивне додавання до файлу, я вибираю режим виправлення. Це дарує мені

diff --git a/newfile b/newfile
index 6d501a3..8b81ae9 100644
--- a/newfile
+++ b/newfile
@@ -1,6 +1,9 @@
+Change supporting feature 1
 first change
 second change off branch
 third change off branch
 second change
 third change
 fourth change
+bug fix 1
+change supporting feature 1

Я відповідаю розділенням, після чого "ні", щоб застосувати перший шматок. Другий кусень, я намагаюся редагувати. Спочатку я намагався видалити нижній рядок - це не спрацювало. Залишити кусень у спокої теж повністю не працює, і я не можу зрозуміти, чому.

Для цього конкретного прикладу вам потрібно налаштувати номери рядків у шматку. Змініть рядок:

@@ -1,6 +2,8 @@

так що замість цього читається:

@@ -2,7 +2,8 @@

Це як у цій публікації git-add ?

Редагувати кусок вручну надзвичайно потужний, але також дещо складний, якщо ви ніколи цього не робили.
Найголовніше, про що слід пам’ятати: різниця завжди має відступи з одним символом на додаток до будь-якого іншого відступу.
Персонаж може бути:

• пробіл (вказує незмінний рядок),
• -вказівка на те, що рядок видалено,
• або +вказівка на те, що рядок додано.

Більш нічого. Це має бути пробіл, a - або +. Будь-що інше, і ви отримаєте помилки
(для зміненого рядка немає символу, оскільки вони обробляються шляхом видалення старого рядка та додавання зміненого як нового).

Оскільки ви відкрили різницю у вашому улюбленому текстовому редакторі (ви налаштували Git на використання вашого улюбленого текстового редактора, чи не так?), Ви можете робити все, що завгодно - до тих пір, поки переконайтесь, що отримана різниця застосовується чисто.

І в цьому полягає вся хитрість. Якщо ви ніколи раніше цього не робили, Git скаже вам "Ваш відредагований шматок не застосовується. Редагувати ще раз?" так часто ти почнеш ненавидіти себе за свою нездатність зрозуміти це , хоча це здається настільки легким (або Git, бо він не може зрозуміти, що ти хочеш).

Щось досить часто мене спотикало, це те, що я забув відступ одного символу.
Я б позначив рядок символом -, який слід видалити, але в більшості текстових редакторів, який вставляє a -, він не перезаписує простір, який був там раніше. Це означає, що ви додаєте додатковий простір до цілого рядка, а це, в свою чергу, означає, що алгоритм diff не може знайти / зрівняти рядок у вихідному файлі, що, в свою чергу, означає, що Git буде кричати на вас .

Інша справа, що різниця все ще має сенс. "Sense" означає, що його можна застосовувати чисто. Саме те, як ви створюєте розумну різницю, здається трохи похмурим мистецтвом (принаймні для мене зараз), але ви завжди повинні пам’ятати, як виглядав оригінальний файл, а потім планувати свої -s та + s відповідно. Якщо ви будете редагувати свої куски досить часто, ви з часом зрозумієте це.

Дивіться також цей коміт на git add -p .

Ortomala Lokni «s відповідь відноситься до Хоакін Windmüller блозі" Вибірково добірних змін зробити з мерзотником (або Імма редагувати ваш красень) "

Замість підрахунку рядків, що Git хотів би зробити, це злити перекриваються шматки (коли їх редагують) перед тим, як застосовувати згаданий відредагований шматок.
Це було обговорено в середині 2018 року і дозволило б уникнути таких сценаріїв, як:

якщо ви розділите шматок, відредагуйте перший підканал, перетворивши кінцевий рядок контексту на видалення, тоді якщо ви спробуєте індексувати другий підханк, це не вдасться.

Звичайно, я запізнююсь із цим, але тим не менш хотів зазначити для протоколу, що це питання обговорювалося минулого року в списку розсилки git, і, схоже, з тих пір мало що змінилося.

Ця особлива проблема випливає з розбиття та спроби редагування одного і того ж шматка. Аналіз, як спочатку розмістив Джефф Кінг, основної проблеми, по суті, полягає в наступному:

Хм Добре, я бачу. Перевірка "чи застосовується ця різниця" подає обидві частини розділеного патча до git-apply. Але, звичайно, друга частина ніколи не застосовуватиметься правильно, оскільки її контекст накладається на першу частину, але не враховує її.

Виконання перевірки за допомогою лише відредагованого виправлення буде працювати. Але це не враховує, що ваш відредагований патч потенційно не вдасться застосувати в довгостроковій перспективі, залежно від того, чи приймаєте ви іншу половину розділеного патча. І ми поки що не можемо цього знати, оскільки користувач, можливо, не сказав нам (вони могли пропустити першу половину, а потім повернутися до неї пізніше після кроку редагування).

Джефф завершує свою публікацію дуже прагматичним обхідним шляхом, який завжди вдається, і тому настійно рекомендується:

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

Вибравши лише редагування шматка, який раніше не був розділений, вам не доведеться мати справу з номерами рядків.

Якщо ви хочете не видаляти рядок, який був призначений для видалення, як у

 first line
-second line
 third line

де ви хочете зберегти другий рядок, переконайтеся, що заміните -пробіл, а не видалите весь рядок (як це було б для позбавлення від доданого рядка). Git буде використовувати рядок для контексту.

Важливо також правильно змінити заголовок куса (наприклад @@ -1,6 +1,9 @@). Хоакін Віндмюллер розкриває секрет редагування заголовків в одному зі своїх дописів у блозі .

Секрети редагування шматків

Спочатку редагування кусочків може заплутати, інструкції, які git надає вам допомогу, але недостатні для початку.

# —||

# To remove ‘-’ lines, make them ’ ’ lines (context).

# To remove ‘+’ lines, delete them.

# Lines starting with # will be removed.

#

# If the patch applies cleanly, the edited hunk will immediately be

# marked for staging. If it does not apply cleanly, you will be given

# an opportunity to edit again. If all lines of the hunk are removed,

# then the edit is aborted and the hunk is left unchanged.

Секретний соус - це ... підрахунок рядків:

• Якщо ви видалите рядок, який починається з +, відніміть один до нового числа рядків (остання цифра заголовка куса) .
• Якщо ви видалите рядок, який починається з - додайте його до нового числа рядків (остання цифра заголовка куса) .
• Не видаляйте інші рядки (посилальні рядки).

Це повинно дозволити вам швидко змінити куски, щоб вибрати потрібні деталі.

Нещодавно я з читання цієї теми зрозумів, як робити ручне редагування.

Фокус, яким я скористався, полягає в тому, що якщо у мене різниця, як:

+ Line to add
+ Line to add
+ Line I dont want to include
+ Line I dont want to include

Фокус полягає в тому, щоб повністю видалити два рядки, які я не хочу, роблячи отриману різницю схожою:

+ Line to add
+ Line to add

Хоча це, швидше за все, очевидно для більшості людей, це було не для мене до сьогодні, і я думав, що повинен просто поділитися своїм досвідом. Скажіть, будь-ласка, чи існує небезпека для цього методу.

Ви можете вручну редагувати номери рядків, що, безумовно, корисно в деяких випадках. Однак ви, мабуть, могли б уникнути цієї конкретної проблеми, НЕ спершу розколюючи шматок.

Якщо ви бачите, що пізніше вам, можливо, доведеться відредагувати щось у комбінації, яку автоматично вибрав Git, найкраще просто відредагувати весь блок, а не розділяти, індексувати половину, а потім редагувати другу половину. Git зробить кращу роботу, з’ясувавши це.

Я прийшов до цього запитання, шукаючи рішення тієї ж проблеми, і не міг зрозуміти, як змінити номери рядків (як пропонувалося вище) у комбінації, щоб git прийняв його у моєму випадку. Я знайшов набагато кращий спосіб зробити це, використовуючи git gui. Там ви можете вибрати рядки в різниці, які ви хочете поставити, потім клацніть правою кнопкою миші та виберіть "Поетапні рядки з коміту". Я пам’ятаю, git-cola теж має таку ж функціональність.

Додатковою проблемою, коли я отримав цю помилку, було те, що закінчення рядків змінилися, коли я зберегла файл редагування.

Я використовував Windows і використовував Блокнот для своїх редагувань (зберігається лише з закінченнями рядків Windows). Мій код був написаний за допомогою Notepad ++, і я налаштував його на закінчення рядків у стилі Unix / Linux.

Коли я змінив свої налаштування на Notepad ++ як редактор git за замовчуванням, я зміг внести свої зміни до багатого.

git config --global core.editor "notepad++"

Однією з причин дивних повідомлень "Ваш відредагований шматок не застосовується" (можливо, супроводжується чимось на кшталт "помилка: фрагмент виправлення без заголовка в рядку ...") може бути ваш редактор, якщо він налаштований на видалення пробілів, що відстають. Це, очевидно, спричиняло б серйозні проблеми, оскільки патчі кодують порожні рядки як рядки з одним пробілом, до якого будь-який блок, що містить порожні рядки, не вдасться застосувати, якщо його зберегти за допомогою такого редактора. Отже, фактично будь-який блок, що містить будь-які незмінені порожні рядки, не зможе застосуватись після редагування, якщо ввімкнено зачищення пробілів.

FYI, я отримував злегка взаємопов’язану помилку ... коли я додав виправлене, дотримуючись запропонованих вище інструкцій ... Однак, помилок не було. Я неодноразово отримував його, просячи мене поставити ту ж саму штуку ... Я помітив, що працюю зі старою версією Vim 7.4 ... Я модернізував vim, і зараз він працює, як очікувалося. Сподіваємось, це комусь допоможе ..