git add --interactive "Your edited hunk does not apply"
Solution 1
For this particular example, you need to tweak the line numbers in the hunk. Change the line:
@@ -1,6 +2,8 @@
so that it instead reads:
@@ -2,7 +2,8 @@
Solution 2
Is this like in this git-add post?
Manually editing the hunk is immensely powerful, but also a bit complicated if you've never done it before.
The most important thing to keep in mind: The diff is always indented with one character in addition to whatever other indentation is there.
The character can either be:
- a space (indicates an unchanged line),
- a
-
indicating that the line was removed,- or a
+
indicating that the line was added.Nothing else. It must be either a space, a - or a +. Anything else, and you'll get errors
(there's no character for a changed line, since those are handled by removing the old line, and adding the changed one as new).Since you've got the diff open in your favorite text editor (you did configure Git to use your favorite text editor, right?), you can do whatever you want - as long as you make sure the resulting diff applies cleanly.
And therein lies the trick. If you've never done this before, Git will tell you "Your edited hunk does not apply. Edit again?" so often, you'll start to hate yourself for your inability to figure this out, even though it seems so easy (or Git because it can't figure out what you want).
One thing that tripped me up quite often was that I forgot the one character indent.
I'd mark a line with a - to be removed, but in most text editors that inserts a-
, it doesn't overwrite the space that was there before. This means you're adding an additional space to the whole line, which in turn means the diff algorithm can't find/match the line in the original file, which in turn means Git will yell at you.The other thing is that the diff still has to make sense. "Sense" means that it can be applied cleanly. Exactly how you create a sensible diff seems to be a bit of an dark art (at least to me right now), but you should always keep in mind how the original file looked like, and then plan your -s and +s accordingly. If you edit your hunks often enough you'll eventually get the hang of it.
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 scenario like:
if you split a hunk, edit the first subhunk, transforming a trailing context line to a deletion then if you try to stage the second subhunk, it will fail.
Solution 3
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:
Hm. OK, I see. The "does this diff apply" check feeds both parts of the split patch to git-apply. But of course the second part will never correctly apply, because its context overlaps with the first part, but doesn't take it into account.
Doing the check with just the edited patch would work. But that doesn't take into account that your edited patch will potentially fail to apply in the long run, depending on whether or not you accept the other half of the split patch. And we can't know that yet, because the user may not have told us (they could have skipped the first half, and then come back to it later after the edit step).
Jeff concludes his post with a very pragmatic workaround that always succeeds, and is thus highly recommended:
So in general, I think splitting and editing the same hunk is inherently dangerous and is going to lead to these sorts of problems. And because editing provides a superset of the functionality, I think you should just edit and either allow the first part of the hunk to be applied or not depending on your preference.
By only choosing to edit a hunk not previously split, you will not have to deal with the line numbers.
Solution 4
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.
The secrets of editing hunks
Editing the hunks can be confusing at first, the instructions that git gives you help but are not enough to get started.
# —|| # 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.
The secret sauce is…counting lines:
- If you remove a line that starts with + then subtract one to the new line count (last digit of the hunk’s header).
- If you remove a line that starts with - then add one to the new line count (last digit of the hunk’s header).
- Don’t remove the other lines (reference lines).
This should allow you to quickly modify the hunks to select the parts you want.
Solution 5
When you want to not delete a line that staged for deletion, as in
first line
-second line
third line
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.
Josh
Updated on October 22, 2021Comments
-
Josh over 2 years
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 withdiff --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.
-
Josh almost 14 yearsAfter some digging, I found that those lines are showing the "from-file range" and "to-file range". I don't really understand the logic behind changing the 1 to a 2. I tried it, and it works, but I don't understand why the "from-file range" changes. The original file is the same, whether I'm applying the whole patch, or just the edited hunk. Can you clarify further, or point me to a descent reference on the unified diff format. I've been unsuccessful in finding one.
-
Josh almost 14 yearsThanks for the link, but I had already seen this. I was not adding/leaving an additional line. The problem was in the line numbers, but I still don't understand the fix.
-
VonC almost 14 years@Josh: stackoverflow.com/questions/2529441/… can help, even if I don't get entirely the Unified format hunks. @William +1
-
William Pursell almost 14 years@Josh: In looking into it it looks like it may be a bug. After you edit the hunk, git attempts to verify the patch by checking that all hunks will apply (this may be excessive). Unfortunately, in this case, that means the previous hunk (which you are not applying) is being checked, and there is some overlap which causes git apply --check to fail. I don't know an elegant solution; git may be doing the right thing by being overly cautious here.
-
okonomichiyaki over 11 yearsThanks, this is indeed way easier than fiddling about with line numbers.
-
pedorro about 9 yearsI was not replacing a deleted '-' with a blank space - thus screwing up the indentation. Thx!!
-
Bill almost 9 yearsMore info on changing the line numbers please? Why do we have to do that? And how? What does each number mean?
-
Annabel about 8 yearsThis worked for me. But I needed the full path to notepad++ and that took a while to get right:
git config --global core.editor '"C:/Program\ Files\ \(x86\)/Notepad++/notepad++.exe"'
(adapt this according to where notepad++ is installed on your PC) -
oligofren over 7 yearsJust make sure you don't misunderstand the blank space part. I thought all unchanged lines should be just a line with a black - instead of merely the indent character ... Had an hour of "edited hunk does not apply" until I understood why :-/
-
VonC over 7 years@oligofren I am not sure I understand you: what did you had to do to make your edited hunk apply?
-
oligofren over 7 years@VonC: I first thought I should change
- foo
into ` ` (just a blank space, not "a blank space and the entire line"). Took me a while to understand it should have been ` foo`. -
VonC over 7 years@oligofren Got it. Thank you for clarifying.
-
JackHasaKeyboard over 7 yearsThis wasn't clear to me, I thought Git was telling me to make the line a single space.
-
samvdst over 7 yearsI can't thank you enough! I was trying to change the
+
into a' '
for at least an hour. -
kleinfreund about 7 yearsWhat? I don’t understand what any of this means.
-
Eido95 about 7 yearsWhere is
@@ -1,6 +2,8 @@
line? -
William Pursell about 7 yearsWhen you are in the interactive mode and split the first hunk, the second hunk has that line.
-
William Pursell about 7 yearsLooks like modern versions of git handle this properly, though.
-
Johnny Oshika almost 7 yearsExact same problem for me. It was Notepad that was causing problems. Once I switched my default editor to Notepad++, everything started to work again.
-
Jamie Deakin almost 7 yearsThis really ought to be the answer.
git-cola
appears to work on Linux, Windows, and MacOS. -
solidak over 6 yearsYou know, craziness is doing the same thing and expecting a different result. I've been saying that to myself for 20 minutes before I figured out that I just needed to delete :)
-
Kyle s about 6 yearsThis was my issue. Needed my hunk to be smaller. Performed a split in interactive. The split was not what I wanted so I decided to try and edit manually. Kept getting the error. Started over, worked first try.
-
Dennis almost 6 yearsIs there a way to automate the editing of the hunk header or configure git to determine the appropriate line counts?
-
Dennis almost 6 years@WilliamPursell what versions of git? I've switched to a new computer and running git v2.17.0 and all of a sudden my patch edits are never valid anymore.
-
Ortomala Lokni almost 6 yearsYou can probably script your favorite editor to automatize this. Maybe there is already some plugins for this, but this is editor dependent.
-
Scymex over 5 years@Dennis I'm experiencing the same thing with git 2.18.0
-
Talus over 5 yearsExperiencing the same also for a while now (I think it was from 2.17)....
-
Ray Salemi about 5 yearsWhatever you do. See @Ortomala Lokni's post below. There is critical information there about additional edits that is not discussed above.
-
Steve Almond almost 5 yearsThanks for the "or a space". I hate significant (and invisible!) whitespace
-
Dr_Zaszuś almost 4 yearsThis is the best answer in this thread. Do not split and edit. Just edit.
-
Dr_Zaszuś almost 4 yearsIn my case, an extra problem was coming from Windows line endings shown as
^M
in the diff file. Once I saved the file with CR endings, the interactive edit patch went through! -
Matthias Fischer almost 4 yearsThanks, this did the trick for me. I had to work on a huge chunk, so I split it down, and everything broke. Keeping it unsplit made everything work fine.
-
Nawaz over 3 yearsHow does this answer help understanding the problem and the solution? It is sad that people mark such post as "accepted answer" only because it solves their current problem but explains absolutely nothing, and ignoring better answers which not only solve the problems but explains it as well.
-
xPeaWhyTee over 3 yearsThis should be the answer. Nice and simple, thanks!
-
Deon McClung about 3 yearsI had this problem using git in Windows. I've found that you don't have to do any line counting or tweak with the header. If Vim is the active editor, simply set the line endings to Unix sometime before your write/quit and git will figure it out. :set ff=unix
-
user2394284 about 2 yearsArgh, why doesn't git just say «Sorry, you can't edit an already split hunk» instead of blaming the user that it «does not apply»? This is a bug: A bug is a deviation between spec and result. As such, when the user follows the edit rules correctly, and it doesn't work, it's a bug.