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

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

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

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

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

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

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

# 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:

# Using dos2unix
dos2unix your-patch.patch

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

# In vim
:set ff=unix
:wq

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:

# 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):

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

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

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

@@ -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).

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

# 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:

# 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.

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

# 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.

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

For git am with email patches:

# 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

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):

# 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:

git add your-file.txt

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