34

I have a Java file that ends like this:

    }
}

And I mistakenly erased the newline at the end some time ago, but it was fine just until today when I got an error message from Git-GUI when commiting

fatal: corrupt patch at line 36

I tried adding the missing newline, but Git seems not to be able to handle it right:

Before adding newline:

     }
 }
\ No newline at end of file

After adding newline:

     }
-}
\ No newline at end of file
+}

And it still gives me that error.

I tried reverting changes and adding only the newline without other changes to the file, but it didn't help either.

EDIT: Adding two or even three newlines doesn't help too.

EDIT2: This error occurs only when commiting lines within the last hunk.

wassup
  • 2,333
  • 2
  • 21
  • 30
  • Likely the same issue as [here](http://stackoverflow.com/questions/12147930/fatal-corrupt-patch-at-line-xx-when-staging-single-line). – mart1n Aug 09 '13 at 09:15
  • @mart1n But no solution. – wassup Aug 09 '13 at 09:30
  • @LucasEasedUp: The solution is easy. Commit from command-line. – Jan Hudec Aug 09 '13 at 09:54
  • 1
    Note: I implicitly assume you are committing from command-line. If you are committing from `git gui` and didn't try it from command-line, you should mention it and try command-line and report whether it works. – Jan Hudec Aug 09 '13 at 09:56
  • @JanHudec I edited my question and mentioned I had used Git Gui. – wassup Aug 09 '13 at 10:07
  • see my answer on http://stackoverflow.com/a/19790903/787883 – Zonko Nov 05 '13 at 14:12
  • 1
    If you are creating the patch on a UNIX-like system and trying to apply it on Windows you'll face the typical EOL problem. I had to change it from CRLF to LF using an editor (VS Code in this case) and after that `git apply` worked fine – sakisk Jul 09 '19 at 07:33

8 Answers8

39

This is happens when you edit '-' lines.
When you remove '-' and forget to add ' ' (space) instead of it

Open your patch and check that all lines you want to leave untouched are started with ' ' (space)

UPDATE

It is also possible that your editor has the option: "Delete spaces at the end of line". So, when you save the patch in your editor:

-Line with space at end <--- NOTICE: Here there is one space at the end
+Line with no space at end<--- Here there's no space

Your editor will remove trailing space and patch become like this:

-Line with space at end<--- Here no space. Patch will FAIL!!!
+Line with no space at end<--- Here no space also

This patch will FAIL because the origin file has no line:

-Line with space at end<---

instead it has:

-Line with space at end <--- 

UPD
Sometimes you want to remove - lines. You change it by whitespace which is trimmed. So this does not work (here is just wihitespace as first character):

 

To workaround this just add + line after it:

-
+

This patch will remove empty line and add it again

Eugen Konkov
  • 22,193
  • 17
  • 108
  • 158
  • 1
    That will mention that the patch does not apply, not that it is corrupt. – Joost Feb 28 '16 at 13:01
  • 2
    Wow as if adding an extra line with just a space made my patch apply – Jake88 Sep 09 '16 at 20:35
  • @Jake88 Than is because of first character is special in patch: ' ' (space) leave line intact, '+' this line is new, '-' this line will be removed, '\' No newline at end of file. Some editors remove alone spaces at line, but this is critical for patches – Eugen Konkov Sep 10 '16 at 08:19
  • Notepad++ with trim trailing spaces was causing this for me. Thank you! – DaBooba Oct 16 '20 at 12:56
  • 1
    @DaBooba: You may configure editor to remove trailing spaces only for lines which you change. This support many modern editors – Eugen Konkov Oct 16 '20 at 13:19
  • @EugenKonkov That's great to know! But that would still fail when removing the '-' on a line that has trailing whitespace because it would be trimmed and cause the same issue. – DaBooba Oct 16 '20 at 17:21
  • 1
    @DaBooba: To remove `-` line you can just add `+` line after it ;-) See **UPD** – Eugen Konkov Oct 17 '20 at 08:41
  • Thanks for this. Both Sublime and Notepad stripped my trailing spaces on copy-paste which corrupted the patch. This answer led me to use Save as... instead of copy-paste which turned out OK. – Adam Hosman Feb 19 '21 at 16:58
  • It happens for the following line I have in my file: `+-------- -------- ----------` – alper Feb 02 '22 at 15:17
14

Another potential issue, especially when editing using a regular text editor, is failing to deal with the numbers at the beginning of the hunk, which denote how many lines are in the old code and how many are in the new code, as well as where it starts in each. If the numbers don't match up, you get the fatal: corrupt patch at line x error.

For example, @@ -32,9 +54,15 @@ tells it to find the code to be replaced at line 32 and for the next 9 lines in the original file, but in the edited file to have fifteen lines starting at line 54. If you add or remove any lines, you'll have to edit those numbers as well.

While I haven't done any real research into it or ever used git gui, it's conceivable that, since lines which don't end in newlines aren't technically lines according to some standards, you'd need to change one or both of those numbers by one to get it to apply correctly.

ejwilson
  • 143
  • 1
  • 5
2

commit does not do anything with patches. It does not even do anything with their content. The commit only formats the tree and commit objects and adjusts the HEAD and the ref it points to. So it's not commit itself that gives this error.

It is not add either, because while it hashes the new file content, it operates on the new content and does not care about differences at all.

The only think that cares about differences is the default pre-commit hook that checks that you are not adding trailing whitespace and few similar problems. You can skip that check by calling git commit --no-verify. But you'd have to have enabled it in the first place and you'd probably know it.

Jan Hudec
  • 73,652
  • 13
  • 125
  • 172
2

Not a direct answer to your question, but I just ran into this error when running git apply something.diff, and the solution was similar enough to your description that I thought it should be posted here for future travelers: something.diff didn't have a blank line at the end. Apparently that last newline is important to git, and it worked as soon as I added it.

Matthew Read
  • 1,365
  • 1
  • 30
  • 50
1

I just had a similar problem (probably equal due to the workings of git gui) to this, which may be useful to anyone having it as well.

When patching my pom.xml via git add -e pom.xml, the patch was the following.

diff --git a/pom.xml b/pom.xml
index 3dba69a..a9c8ebb 100644
--- a/pom.xml
+++ b/pom.xml
@@ -1,26 +1,48 @@
 <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
     <modelVersion>4.0.0</modelVersion>
     <groupId>adowrath</groupId>
     <artifactId>project-name</artifactId>
     <version>0.0.1</version>
+    <properties>
+        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
+    </properties>
     <build>
         <sourceDirectory>src/main/java</sourceDirectory>
         <testSourceDirectory>src/test/java</testSourceDirectory>
         <plugins>
             <plugin>
                 <artifactId>maven-compiler-plugin</artifactId>
                 <version>3.6.1</version>
                 <configuration>
                     <source>1.8</source>
                     <target>1.8</target>
                 </configuration>
             </plugin>
             <plugin>
+                <groupId>org.jacoco</groupId>
+                <artifactId>jacoco-maven-plugin</artifactId>
+                <version>0.7.9</version>
+                <executions>
+                    <execution>
+                        <goals>
+                            <goal>prepare-agent</goal>
+                        </goals>
+                    </execution>
+                    <execution>
+                        <id>report</id>
+                        <phase>test</phase>
+                        <goals>
+                            <goal>report</goal>
+                        </goals>
+                    </execution>
+                </executions>
+            </plugin>
+            <plugin>
                 <artifactId>maven-surefire-plugin</artifactId>
                 <version>2.16</version>
                 <configuration>
                     <includes>
                         <include>**/Test*.java</include>
                         <include>**/*Test.java</include>
                         <include>**/*Tests.java</include>
@@ -32,9 +54,15 @@
     </build>
     <dependencies>
         <dependency>
             <groupId>junit</groupId>
             <artifactId>junit</artifactId>
             <version>4.12</version>
         </dependency>
+        <dependency>
+            <groupId>org.mockito</groupId>
+            <artifactId>mockito-core</artifactId>
+            <version>2.5.5</version>
+            <scope>test</scope>
+        </dependency>
     </dependencies>
 </project>

And I wanted to remove the last block with the Mockito-dependency. If I just remove the lines itself, it always gives me an error reporting to line 64:

fatal: corrupt patch at line 64
fatal: Could not apply '.git/ADD_EDIT.patch'

Line 64 is the last line in the patch file, so the line after <project>.

The solution was to simply remove the whole trunk, so everything from the @@-line downwards, and it worked immediately.

I hope this helps.

Adowrath
  • 701
  • 11
  • 24
1

I had this same issue, and finally figured out what it was. Some of my lines were indented with tabs instead of spaces. After changing all my indentation to spaces, it worked.

baldguy99
  • 21
  • 3
1

And I wanted to remove the last block with the Mockito-dependency.
If I just remove the lines itself, it always gives me an error reporting to line 64:

fatal: corrupt patch at line 64
fatal: Could not apply '.git/ADD_EDIT.patch'

You should not see that kind of error now (Q1 2019) with Git 2.21+, since before 2.21, "git add -e" got confused when the change it wants to let the user edit is smaller than the previous change that was left over in a temporary file.

add --edit: truncate the patch file

If there is already a .git/ADD_EDIT.patch file, we fail to truncate it properly, which could result in very funny errors.

Of course, this file should not be left lying around.
But at least in one case, there was a stale copy, larger than the current diff. So the result was a corrupt diff.

Let's just truncate the file when we write it and not worry about it too much.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
0

Ok, sorry for not checking it thoroughly.

I tried adding and commiting as I would normally do, but without Git-GUI, using command-line, and it worked.

And so, I'd recommend everyone that has problems with Git-GUI not to do like I did and check it through command-line before posting.

wassup
  • 2,333
  • 2
  • 21
  • 30