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将“bug fix 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
我用分裂来回应，然后用“不”来应用第一个块。第二个大块头，我尝试编辑。我最初尝试删除底线 - 但没有成功。完全让这个大块头单独呆着也是行不通的，我不明白为什么。
I'm trying to use git add --interactive to selectively add some changes to my index, but I continually receive the "Your edited hunk does not apply. Edit again..." message. I get this message even if I choose the e option, and immediately save/close my editor. In other words, without editing the hunk at all, the patch doesn't apply.
Here's the exact example I'm using (I'm trying to put together a small demo):
Original file:
first change
second change off branch
third change off branch
second change
third change
fourth change
New file:
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
I'm trying to show how to use git add --interactive to only add the "bug fix 1" line to the index. Running interactive add on the file, I choose the patch mode. It presents me with
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
I respond with split, followed by "no" to apply the first hunk. The second hunk, I try to edit. I originally tried deleting the bottom line - that didn't work. Leaving the hunk alone completely doesn't work either, and I can't figure out why.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（13）
这是否像这篇 git-add 帖子中那样？
另请参阅在 git add -p 上提交。
Ortomala Lokni 的答案< /a> 引用 Joaquín Windmüller 博客文章“有选择地选择要使用 git 提交的更改（或者我要编辑你的块）”
Git 想要做的不是计算行数，而是在应用所述编辑后的块之前合并重叠的块（当一个块被编辑时） .
这是在 2018 年中期讨论过的，避免出现以下情况：
使用 Git 2.45（2024 年第 2 季度），第 16 批，“
git add -p"(man) 和其他交互式块选择 UI 已经学会在块显示后立即跳过显示块，以及明确要求重新显示当前块的附加操作。在您的情况下，在出现“
您编辑的块不适用。再次编辑...”错误消息后，不适用的块将不会重复。请参阅 提交 bab1f1c、提交 66c14ab（2024 年 3 月 29 日），作者：Rubén Justo （
rjusto）。（由 Junio C Hamano --
gitster-- 合并于 提交 989bf45，2024 年 4 月 9 日）但你也有：
git add现在包含在其 手册页：您可以随时使用
p检查交互式补丁会话中的当前块。Is this like in this git-add post?
See also this commit on git add -p.
Ortomala Lokni's answer refers to Joaquín Windmüller blog post "Selectively select changes to commit with git (or Imma edit your hunk)"
Instead of counting lines, what Git would like to do is to coalesce overlapping hunks (when one is edited) before applying said edited hunk.
That was discussed mid-2018, and would avoid scenarios like:
With Git 2.45 (Q2 2024), batch 16, "
git add -p"(man) and other interactive hunk selection UI has learned to skip showing the hunk immediately after it has already been shown, and an additional action to explicitly ask to reshow the current hunk.In your case, the hunk which does not apply will not be repeated after a "
Your edited hunk does not apply. Edit again..." error message.See commit bab1f1c, commit 66c14ab (29 Mar 2024) by Rubén Justo (
rjusto).(Merged by Junio C Hamano --
gitster-- in commit 989bf45, 09 Apr 2024)But you also have:
git addnow includes in its man page:You can inspect at any time the current hunk in your interractive patch session with
p.当然，我迟到了，但还是想记录一下这个问题 去年在 git 邮件列表上进行了讨论，从那以后看起来没有太大变化。
这个特殊问题源于分裂和尝试编辑同一个块。正如 Jeff King 最初发布的那样，对根本问题的分析基本上是：
Jeff 以一种非常务实的解决方法结束了他的文章，该解决方法总是成功，因此强烈推荐：
通过仅选择编辑先前未分割的块，您将不必处理行号。
Of course I'm late to this but nevertheless wanted to mention for the record that this issue was discussed last year on the git mailing list and it looks like not much has changed since.
This particular issue stems from splitting and attempting to edit the same hunk. The analysis, as originally posted by Jeff King, of the underlying problem essentially is:
Jeff concludes his post with a very pragmatic workaround that always succeeds, and is thus highly recommended:
By only choosing to edit a hunk not previously split, you will not have to deal with the line numbers.
对于这个特定的示例，您需要调整块中的行号。更改行：
，使其改为：
For this particular example, you need to tweak the line numbers in the hunk. Change the line:
so that it instead reads:
正确修改 hunk 标头（例如
@@ -1,6 +1,9 @@）也很重要。 Joaquin Windmuller 在他的一篇 博客文章。It's important to also correctly modify the hunk header (e.g.
@@ -1,6 +1,9 @@). Joaquin Windmuller reveal the secret of hunk header editing in one of his blog post.当您不想删除暂存待删除的行时，例如
您想要保留第二行的位置，请确保将
-替换为空格，而不是删除整行（如您会删除添加的行）。 Git 将使用该行作为上下文。When you want to not delete a line that staged for deletion, as in
where you want to keep the second line, make sure you replace the
-with a space, rather than deleting the whole line (as you would to get rid of an added line). Git will use the line for context.我最近通过阅读这篇文章弄清楚了如何进行手动编辑。
我使用的技巧是，如果我有这样的差异：
技巧是完全删除我不想要的两行，使生成的差异看起来像：
虽然这对大多数人来说很可能是显而易见的，但它不适合我直到今天，我想我应该分享我的经验。请告诉我这种方法是否有任何危险。
I recently figured out from reading this thread how to do the manual editing.
The trick I used was that if I have a diff like:
The trick is to completely remove the two lines I don't want, making the resulting diff looking like:
While this is most likely obvious to most people, it was not for me until today and I thought I should just share my experience. Please tell me if there is any danger to this method.
您可以手动编辑行号，这在某些情况下绝对有用。但是，您可能可以通过不首先拆分大块来避免这个特定问题。
如果您发现稍后可能需要在 Git 自动选择的块中编辑某些内容，那么最好只编辑整个块，而不是拆分、暂存一半，然后编辑另一半。 Git 会更好地解决这个问题。
You can manually edit the line numbers, that's definitely useful in some cases. However, you probably could have avoided this particular problem by NOT first splitting the hunk.
If you see that you'll probably need to edit something later in the hunk that Git has automatically chosen, it's best to just edit the whole hunk rather than splitting, staging half, and then editing the other half. Git will do a better job figuring that out.
我来到这个问题寻找相同问题的解决方案，并且无法弄清楚如何更改大块中的行号（如上所述）以使 git 在我的情况下接受它。不过，我找到了一种更好的方法来使用 git gui 来做到这一点。在那里，您可以选择差异中要暂存的行，然后右键单击并选择“从提交暂存行”。我记得 git-cola 也有相同的功能。
I came to this question looking for solution to same problem, and couldn't figure out how to change the line numbers (as suggested above) in the hunk to get git accept it in my case. I found a much better way to do that using
git guithough. There you can select the lines in the diff that you want to stage, then right click and choose "Stage lines from commit". I remember git-cola has the same functionality too.奇怪的“你编辑的块不适用”消息（可能伴随着类似“错误：补丁片段在行中没有标题”）的原因之一可能是你的编辑器，如果它配置为去除尾随空格。这显然会导致重大问题，因为补丁将空行编码为带有一个空格的行，如果使用这样的编辑器保存，任何包含空行的块都将无法应用。因此，实际上，如果启用了剥离尾随空格，则任何包含任何未更改的空行的块在编辑后都将无法应用。
One reason for weird "Your edited hunk does not apply" messages (likely accompanied with something like "error: patch fragment without header at line...") might be your editor if it's configured to strip trailing whitespace. This would obviously cause major problems as patches encode empty lines as lines with one space any hunk containing empty lines would fail to apply if saved with such an editor. So in effect any hunk containing any unchanged empty lines would fail to apply after editing with if stripping trailing whitespace is on.
当我收到此错误时遇到的另一个问题是，当我保存编辑文件时，行结尾发生了变化。
我使用 Windows 并使用记事本进行编辑（仅使用 Windows 行结尾保存）。我的代码是用 Notepad++ 编写的，我将其设置为具有 Unix/Linux 样式的行结尾。
当我更改设置以将 Notepad++ 作为默认 git 编辑器时，我可以对这个块进行编辑。
An additional problem I had when I got this error was that the line endings changed when I saved the edit file.
I was using Windows and using Notepad for my edits (only saves with Windows line-endings). My code was written with Notepad++ and I set it up to have Unix/Linux style line endings.
When I changed my settings to have Notepad++ as the default git editor I was able to make my edits to the hunk.
一般来说，问题可能是补丁未正确完成，或者是我将在帖子底部描述的更具体的问题，
如何在 VIM 中编辑
如果< code>vim 是编辑器，将光标放在行中的第一个字符上，然后执行以下操作（假设您处于默认的命令模式或按
esc）基于当前字符和您想要执行的操作：对于以“
”空格开头的行，表示未更改：r-对于以“<”开头的行code>-' 表示它将被删除（或替换）：
r（即先按 r，然后按空格）对于带有 '
+' 的星号行，这意味着它将被添加（或替换 '-' 之前的行）：dd处理行顺序问题
另外，您可能希望移动各行，以便
+行位于之后-行，否则+添加的行将移动到未更改的行之后，如下例所示：假设您在编辑之前有以下补丁：
并且您只想暂存第一行，请勿执行以下操作：
因为这会导致
NewLine1在Line2之后结束！ （除非这是您想要的），而是使用 此处描述的 VIM 命令保存
完成后，只需输入
:wq就可以了。错误的另一个原因
如果在执行补丁
git add时也从外部修改了更改，您也可能会收到此错误消息（即使您正确执行了所有操作）。（例如，您使用另一个终端或 GUI 来暂存更改。）
这会导致实际尝试应用更改时行号失败。
在这种情况下，您应该先退出（通过使用“
q”等），然后重新启动。The issue might be in general that the patch wasn't done correctly or a more specific issue that I will describe in the bottom of the post,
How to Edit in VIM
The way you should do it if
vimis the editor, is by placing the cursor over the first character in the line, and do the following (assuming you are in command mode which is the default or after pressingesc) based on the current character and what you want to do:For a line that starts with a '
' space which means unchanged:r-For a line that starts with a '
-' which means it will be removed (or replaced):r(that's r and then space)For a line that was stars with a '
+' which means it will be add (or replace the '-' line before):ddHandling the line order issue
Also you would probably want to move around lines so that the
+line is right after the-line otherwise the+added line will be moved after the unchanged lines, as in this example:Say you have the following patch before editing:
And you want to only stage the first line, the DO NOT do the following:
as it will cause
NewLine1to end up AFTERLine2! (unless this is what you want), instead move around the lines using the VIM commands described hereSaving
Once you are done just type
:wqand you should be fine.Another cause of the error
You can also get this error message (even if you did everything correctly) if while going through the patches
git addthe changes were also modified externally.(For example you used another terminal or GUI to stage changes.)
This causes the line numbers to fail when actually trying to apply the changes.
In this case you should rather quit first (by using '
q' etc.) and then restart.我曾经有过这个问题。如果使用 VIM 在 Windows 中进行交互式添加，则不必调整块标头（@@ 之间的内容），您所要做的就是将文件行结尾设置为 Unix (LF)。
在 VIM 编辑器中，只需在写入/退出之前执行以下命令：
I used to have this problem. If doing an interactive add in windows, using VIM, you don't have to tweak the hunk header (the stuff between the @@'s), all you have to do is set the file line endings to Unix (LF).
In the VIM editor, simply do the following command sometime before your write/quit:
仅供参考，我遇到了一个稍微相关的错误...当我按照上面建议的说明添加修补程序时...但是，它没有显示任何错误。我不断收到它要求我上演同样的大块...我注意到我正在运行旧版本的 Vim 7.4...我升级了 vim，它现在按预期工作。希望这会帮助某人..
FYI, I was getting a slightly interrelated error... when I add patched following the suggested instruction above... It was showing no error, however. I was getting it repeatedly asking me to stage the same hunk... I noticed I was running an older version of Vim 7.4... I upgraded vim and it's working as expected now. Hopefully this will help someone..