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 ?

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

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

Ничего больше. Это должен быть пробел, - или +. Что-нибудь еще, и вы получите ошибки
(для измененной строки нет символа, так как они обрабатываются путем удаления старой строки и добавления измененной как новой).

Поскольку в вашем любимом текстовом редакторе открыт diff (вы ведь настроили Git для использования вашего любимого текстового редактора, не так ли?), Вы можете делать все, что захотите, при условии, что вы убедитесь, что полученный diff применяется чисто.

И в этом вся хитрость. Если вы никогда не делали этого раньше, Git скажет вам: «Ваш отредактированный кусок не применяется. Изменить снова?» так часто вы начинаете ненавидеть себя за свою неспособность понять это , даже если это кажется таким простым (или Git, потому что он не может понять, чего вы хотите).

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

Другое дело, что разница все еще должна иметь смысл. «Смысл» означает, что его можно наносить чисто. То, как вы создаете разумную разницу, кажется чем-то вроде темного искусства (по крайней мере, для меня сейчас), но вы всегда должны помнить, как выглядел исходный файл, а затем планировать свои -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 accept его в моем случае. Я нашел гораздо лучший способ сделать это, используя git gui. Там вы можете выбрать строки в различии, которые вы хотите подготовить, затем щелкните правой кнопкой мыши и выберите «Строки этапа из фиксации». Я помню, что у git-cola такая же функциональность.

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

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

Когда я изменил свои настройки, чтобы использовать Notepad ++ в качестве редактора git по умолчанию, я смог внести свои изменения в кусок.

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

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

FYI, я получал слегка взаимосвязанную ошибку ... когда я добавлял исправление, следуя предложенной выше инструкции ... Однако ошибки не было. Я получал его неоднократно, прося меня подготовить один и тот же кусок ... Я заметил, что использую старую версию Vim 7.4 ... Я обновил vim, и теперь он работает, как ожидалось. Надеюсь, это кому-то поможет ..