How to fix fatal: bad revision 'HEAD~5..HEAD' in Git

GitBEGINNERLOWUpdated Dec 6, 2025· 151 views

This error occurs when Git cannot resolve the revision range specified in git format-patch. Common causes include not having enough commits in the repository, working with a shallow clone, or referencing commits that don't exist.

Quick fix

Fixes fatal: bad revision 'HEAD~5..HEAD'

git rev-list --count HEAD
  1. Check how many commits exist in your repository
  2. Adjust the range to match available commits
  3. Check if you're in a shallow clone and fetch more history
  4. Handle empty repositories (unborn HEAD)
git — error
git rev-list --count HEAD
fatal: bad revision 'HEAD~5..HEAD'

What this error means

When you run `git format-patch HEAD~5..HEAD`, Git tries to create patch files for the last 5 commits by resolving the revision range. The `HEAD~5` syntax means "go back 5 commits from HEAD." If your repository doesn't have 5 commits yet, or if you're working with a shallow clone that truncated the history, Git cannot find this reference and fails with "bad revision." The error can also occur in completely empty repositories where HEAD doesn't point to any commit yet (called an "unborn branch"). In this state, any reference to HEAD will fail since there's no commit history to traverse. This is commonly encountered in CI/CD pipelines where shallow clones are used to speed up checkout times, or when working with newly initialized repositories that don't have enough commit history for the specified range.

Typical symptoms

  • git format-patch command fails with 'fatal: bad revision' error
  • The error occurs when specifying a range like HEAD~N..HEAD where N exceeds commit count
  • CI/CD pipelines fail when trying to generate patches from shallow clones
  • Error appears in newly created repositories with few commits
  • The command works with smaller ranges but fails with larger ones

Common causes

  1. The repository has fewer commits than the range specified (e.g., HEAD~5 but only 3 commits exist)
  2. Working with a shallow clone where history is truncated (common in CI/CD environments)
  3. The repository is empty with no commits (unborn HEAD)
  4. The branch reference doesn't exist or is corrupted
  5. Using wrong branch name or commit reference that doesn't exist
  6. The .git/HEAD file is corrupted or points to a non-existent branch

How to fix "fatal: bad revision 'HEAD~5..HEAD'"

1Check how many commits exist in your repository

First, determine how many commits are available in your current branch:

bash
git rev-list --count HEAD

If this returns a number smaller than the range you're trying to use (e.g., returns 3 but you're using HEAD~5), that's the problem. You can also view recent commits:

bash
git log --oneline

This shows commit history so you can see exactly how many commits exist.

2Adjust the range to match available commits

If you have fewer commits than requested, adjust your range accordingly:

bash
# If you have 3 commits, use HEAD~3 instead of HEAD~5
git format-patch HEAD~3..HEAD

# Or create patches for all commits since root
git format-patch --root HEAD

# For a single commit patch
git format-patch -1 HEAD

To dynamically use all available commits:

bash
# Get the count and use it
COUNT=$(git rev-list --count HEAD)
git format-patch HEAD~$COUNT..HEAD
3Check if you're in a shallow clone and fetch more history

Shallow clones truncate history to speed up cloning. Check if your repository is shallow:

bash
git rev-parse --is-shallow-repository

If this returns "true", fetch more history:

bash
# Fetch complete history
git fetch --unshallow

# Or fetch a specific depth
git fetch --depth=100

In CI/CD configurations, you can prevent shallow cloning:

GitHub Actions:

yaml
- uses: actions/checkout@v4
  with:
    fetch-depth: 0  # Fetch all history

GitLab CI:

yaml
variables:
  GIT_DEPTH: 0  # Fetch all history
4Handle empty repositories (unborn HEAD)

If the repository has no commits yet, HEAD doesn't exist:

bash
# Check if HEAD exists
git rev-parse HEAD

If this fails with "bad revision 'HEAD'", you need to create at least one commit first:

bash
# Create initial commit
git add .
git commit -m "Initial commit"

# Now format-patch will work
git format-patch -1 HEAD
5Use the root commit for patches since beginning

To create patches from the very first commit, use the --root option:

bash
# Create patches for all commits
git format-patch --root

# Create patches from root to specific commit
git format-patch --root <commit-hash>

# Get root commit hash
git rev-list --max-parents=0 HEAD

This is useful when you need patches for all commits regardless of how many exist.

6Verify and repair corrupted HEAD reference

If HEAD is corrupted, you may need to repair it:

bash
# Check current HEAD state
cat .git/HEAD

# Should show something like: ref: refs/heads/main
# If empty or corrupted, reset it:
git symbolic-ref HEAD refs/heads/main

# Verify repository integrity
git fsck --full

If fsck reports errors, you may need to restore from a backup or re-clone the repository.

Advanced notes

### Using format-patch in CI/CD Pipelines

When automating patch generation in CI/CD, always account for shallow clones:

bash
# Safe script that handles any commit count
COMMITS=$(git rev-list --count HEAD 2>/dev/null || echo 0)
if [ "$COMMITS" -eq 0 ]; then
    echo "No commits found"
    exit 1
elif [ "$COMMITS" -lt 5 ]; then
    git format-patch --root HEAD
else
    git format-patch HEAD~5..HEAD
fi

### Difference Between ~ and ^ in Git

Understanding Git's revision syntax helps avoid these errors:

- HEAD~N - Go back N generations following first parent (linear history)
- HEAD^N - Go to the Nth parent of a merge commit
- HEAD~3 is equivalent to HEAD~~~ or HEAD^^^^ following first parents

### Creating Patches for Specific Commits

Instead of using ranges, you can specify exact commits:

bash
# Single commit
git format-patch -1 abc1234

# Between two specific commits
git format-patch abc1234..def5678

# Using branch comparison
git format-patch origin/main..HEAD

### Format-patch vs diff

- git format-patch creates email-formatted patches with commit metadata
- git diff creates raw diffs without commit information
- Use git am to apply format-patch output, git apply for raw diffs

Frequently asked questions

What does "fatal: bad revision 'HEAD~5..HEAD'" mean?
HEAD, Git tries to create patch files for the last 5 commits by resolving the revision range. " The error can also occur in completely empty repositories where HEAD doesn't point to any commit yet (called an "unborn branch"). In this state, any reference to HEAD will fail since there's no commit history to traverse.
How do I fix "fatal: bad revision 'HEAD~5..HEAD'"?
This error occurs when Git cannot resolve the revision range specified in git format-patch. Common causes include not having enough commits in the repository, working with a shallow clone, or referencing commits that don't exist.
What causes "fatal: bad revision 'HEAD~5..HEAD'"?
The repository has fewer commits than the range specified (e.g., HEAD~5 but only 3 commits exist) Working with a shallow clone where history is truncated (common in CI/CD environments) The repository is empty with no commits (unborn HEAD)
Is the "fatal: bad revision 'HEAD~5..HEAD'" error serious?
It is a low-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading