How to fix fatal: corrupt patch at line 10 in Git

GitINTERMEDIATEMEDIUMUpdated Dec 6, 2025· 284 views

This error occurs when Git cannot parse a patch file due to formatting issues such as missing trailing newlines, stripped whitespace on empty context lines, incorrect hunk line counts, or Windows line endings. Fixing the patch file structure resolves the issue.

Quick fix

Fixes fatal: corrupt patch at line 10

# Check if file ends with newline
tail -c 1 your-patch.patch | od -c
  1. Check for missing trailing newline
  2. Verify line endings are correct
  3. Restore stripped whitespace on empty context lines
  4. Verify hunk header line counts
git — error
# Check if file ends with newline
tail -c 1 your-patch.patch | od -c
fatal: corrupt patch at line 10

What this error means

When Git reports `fatal: corrupt patch at line N`, it means the patch file has structural problems that prevent Git from parsing it correctly. The line number in the error message indicates where Git encountered the problem, but the actual issue may originate earlier in the file. Patches follow a strict format called unified diff format. Each change begins with a hunk header (lines starting with `@@`) that specifies line counts, followed by context lines (prefixed with a space), removed lines (prefixed with `-`), and added lines (prefixed with `+`). If any of these elements are malformed, Git cannot apply the patch. The most common causes are subtle formatting issues: editors that strip trailing whitespace remove the required space on empty context lines, missing newlines at the end of the patch file, or line ending mismatches between Windows (CRLF) and Unix (LF) systems.

Typical symptoms

  • git apply fails with 'fatal: corrupt patch at line N' where N varies based on the issue location
  • git am fails when applying patches received via email
  • git-gui shows 'corrupt patch' error when staging individual lines or hunks
  • Patches created on one operating system fail to apply on another
  • Manually edited patches fail to apply even though they look correct
  • CI/CD pipeline fails when applying generated patches

Common causes

  1. Missing newline at the end of the patch file
  2. Empty context lines have their leading space character stripped by editors with 'remove trailing whitespace' enabled
  3. Windows line endings (CRLF) in a patch file being applied on Unix/Linux
  4. Hunk header line counts do not match the actual number of lines in the hunk
  5. Patch file was corrupted during email transmission (quoted-printable encoding issues)
  6. Copy-paste from web pages introduced encoding artifacts or stripped characters
  7. Source file lacks trailing newline and git-gui cannot stage partial changes

How to fix "fatal: corrupt patch at line 10"

1Check for missing trailing newline

The most common cause is a missing newline at the end of the patch file. Check if the file ends with a newline:

bash
# Check if file ends with newline
tail -c 1 your-patch.patch | od -c

If you see 0000000 with no \n, add a newline:

bash
# Add trailing newline
echo '' >> your-patch.patch

Alternatively, open the file in your editor and ensure there's a blank line at the end.

2Verify line endings are correct

Check if the patch file has Windows line endings (CRLF):

bash
# Check for CRLF line endings
file your-patch.patch

# Or look for ^M characters
cat -A your-patch.patch | head -20

If you see 'CRLF' or ^M at line ends, convert to Unix format:

bash
# Using dos2unix
dos2unix your-patch.patch

# Or using sed
sed -i 's/\r$//' your-patch.patch

# In vim
:set ff=unix
:wq
3Restore stripped whitespace on empty context lines

If your editor removes trailing whitespace, empty context lines in the patch lose their required leading space. Look for lines that should have a single space but are completely empty:

bash
# Show line contents with visible characters
cat -A your-patch.patch

Context lines should start with a space character. If you see two consecutive $ markers (empty lines where there should be a space), you need to restore the spaces.

Fix in your editor: Disable 'remove trailing whitespace' setting when editing patches, or manually add a space to empty context lines.

Fix with sed (add space to empty lines between hunk header and next hunk/end):

bash
sed -i '/^$/s/^/ /' your-patch.patch

Note: This adds a space to ALL empty lines, which may not be correct. Manual editing is safer.

4Verify hunk header line counts

If you've manually edited the patch, the line counts in hunk headers may be wrong. Hunk headers look like:

bash
@@ -32,9 +54,15 @@

This means:
- -32,9: Starting at line 32 in the original file, show 9 lines
- +54,15: Starting at line 54 in the new file, show 15 lines

The 'before' count (9) should equal: context lines + removed lines (- prefix)
The 'after' count (15) should equal: context lines + added lines (+ prefix)

Count the lines manually and correct the header if needed. When count is 1, it can be omitted (e.g., -32 instead of -32,1).

5Validate the patch before applying

Use Git's built-in validation to check the patch without applying it:

bash
# Check if patch is valid
git apply --check your-patch.patch

# Show what would be applied (verbose)
git apply --stat your-patch.patch

For patches meant to be applied with git am:

bash
# Dry run for git am
git am --dry-run your-patch.patch

This helps identify the exact line causing issues without modifying your working directory.

6Regenerate the patch if possible

If you have access to the original commits, regenerating the patch is often easier than fixing a corrupted one:

bash
# Generate patch from a single commit
git format-patch -1 <commit-hash>

# Generate patch from a range of commits
git format-patch <base-commit>..<head-commit>

# Generate diff (simpler format, but less metadata)
git diff <base-commit> <head-commit> > changes.patch

git format-patch creates patches with proper formatting and metadata that are less prone to corruption than raw diff output.

7Handle email-corrupted patches

Patches received via email may have encoding issues. Common problems include quoted-printable encoding and wrapped long lines.

For git am with email patches:

bash
# Keep CR characters if patch was created on Windows
git am --keep-cr your-patch.patch

# Specify transfer encoding (Git 2.3.0+)
git am --transfer-encoding=base64 your-patch.patch

If the patch was corrupted by email, ask the sender to:
1. Use git send-email instead of attaching patches
2. Or compress the patch before attaching: gzip your-patch.patch

8Fix git-gui corrupt patch when staging lines

If you get 'corrupt patch' in git-gui when staging individual lines, the issue is usually that your file doesn't end with a newline.

Solution: Add a trailing newline to your source file (not the patch):

bash
# Check if file ends with newline
tail -c 1 your-file.txt | od -c

# Add newline if missing
echo '' >> your-file.txt

Alternatively, stage the entire file instead of individual lines:

bash
git add your-file.txt

This is a known limitation in git-gui when handling files without trailing newlines.

Advanced notes

Understanding unified diff format: The unified diff format has strict requirements. Each hunk begins with @@ -l,s +l,s @@ where l is the starting line and s is the number of lines. Context lines must start with exactly one space character. Missing or extra characters corrupt the patch.

Why empty context lines need a space: In unified diff, a line that's unchanged between versions is called a context line and must be prefixed with a single space. An empty line in the original file becomes a line containing only a space in the diff. Editors that strip trailing whitespace remove this space, corrupting the patch.

Patch validation tools: Besides git apply --check, you can use patch --dry-run < file.patch to test patches. The GNU patch command sometimes gives more descriptive error messages.

Binary patches: If your patch includes binary files, ensure they're properly encoded. Use git format-patch --binary when creating patches that include binary content.

Large patches: For very large patches, consider splitting them into smaller pieces using git format-patch with commit ranges. This makes debugging easier and reduces the chance of corruption during transmission.

Frequently asked questions

What does "fatal: corrupt patch at line 10" mean?
When Git reports fatal: corrupt patch at line N, it means the patch file has structural problems that prevent Git from parsing it correctly. The line number in the error message indicates where Git encountered the problem, but the actual issue may originate earlier in the file. Patches follow a strict format called unified diff format.
How do I fix "fatal: corrupt patch at line 10"?
This error occurs when Git cannot parse a patch file due to formatting issues such as missing trailing newlines, stripped whitespace on empty context lines, incorrect hunk line counts, or Windows line endings. Fixing the patch file structure resolves the issue.
What causes "fatal: corrupt patch at line 10"?
Missing newline at the end of the patch file Empty context lines have their leading space character stripped by editors with 'remove trailing whitespace' enabled Windows line endings (CRLF) in a patch file being applied on Unix/Linux
Is the "fatal: corrupt patch at line 10" error serious?
It is a medium-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading