How to fix fatal: bad revision 'abc1234' in Git

GitBEGINNERLOWUpdated Dec 6, 2025· 209 views

This error occurs when Git cannot find the commit you're trying to cherry-pick. The most common cause is that the commit exists on a remote branch that hasn't been fetched locally. Fetching from the remote usually resolves the issue.

Quick fix

Fixes fatal: bad revision 'abc1234'

# Fetch all branches from all remotes
git fetch --all

# Then retry the cherry-pick
git cherry-pick abc1234
  1. Fetch the latest commits from all remotes
  2. Verify the commit hash exists
  3. Pull the branch containing the commit
  4. Add the remote repository if cherry-picking across repos
git — error
# Fetch all branches from all remotes
git fetch --all
# Then retry the cherry-pick
git cherry-pick abc1234
fatal: bad revision 'abc1234'

What this error means

When you run `git cherry-pick <commit-hash>`, Git attempts to locate that specific commit in your local repository's object database. The "fatal: bad revision" error means Git cannot find any object (commit, tag, or branch) matching the identifier you provided. Git stores commits locally, and your repository only knows about commits that have been fetched from remotes or created locally. If you're trying to cherry-pick a commit that exists in a teammate's branch or a remote repository, your local Git simply doesn't have that commit in its database yet. This error can also occur if the commit hash is mistyped, the commit was garbage collected after its branch was deleted, or you're using an incorrect syntax for specifying commit ranges. Understanding Git's distributed nature is key to resolving this issue - commits must exist locally before you can operate on them.

Typical symptoms

  • Git displays 'fatal: bad revision <hash>' when running cherry-pick
  • Cherry-pick works for some commits but fails for others from remote branches
  • The commit hash appears valid when viewed on GitHub/GitLab but fails locally
  • Error occurs after pulling changes but before fetching all branches
  • Previously working cherry-pick commands suddenly fail after repository cleanup

Common causes

  1. The commit exists on a remote branch that hasn't been fetched locally
  2. The commit hash is mistyped or truncated incorrectly
  3. The commit was garbage collected after its branch was deleted
  4. You're trying to cherry-pick from a different repository without adding it as a remote
  5. Using incorrect syntax for commit ranges (e.g., using '-' instead of '..')
  6. The repository is a shallow clone that doesn't include the commit history

How to fix "fatal: bad revision 'abc1234'"

1Fetch the latest commits from all remotes

The most common fix is to fetch commits from the remote before cherry-picking. Your local repository may not know about commits that exist only on the remote server.

bash
# Fetch all branches from all remotes
git fetch --all

# Then retry the cherry-pick
git cherry-pick abc1234

If you only need commits from a specific remote:

bash
# Fetch from origin only
git fetch origin

# Fetch a specific branch
git fetch origin feature-branch

After fetching, Git will have the commit in its local object database, and the cherry-pick should succeed.

2Verify the commit hash exists

Before cherry-picking, confirm the commit actually exists and you have the correct hash.

bash
# Check if the commit exists locally
git show abc1234

# If this also shows "bad revision", the commit isn't in your local repo

If the commit exists on a remote:

bash
# View the commit on a remote branch (after fetching)
git log origin/main --oneline | grep abc1234

# Or search all branches
git branch -a --contains abc1234

Get the full commit hash from a short hash:

bash
# Expand short hash to full hash
git rev-parse abc1234

If rev-parse fails, the commit definitely doesn't exist locally.

3Pull the branch containing the commit

If the commit is on a specific branch, make sure that branch's data is up to date locally.

bash
# If the commit is on 'feature-x' branch
git checkout feature-x
git pull origin feature-x

# Switch back to your branch
git checkout your-branch

# Now cherry-pick should work
git cherry-pick abc1234

Alternative without switching branches:

bash
# Fetch and update the remote tracking branch
git fetch origin feature-x:refs/remotes/origin/feature-x

# Cherry-pick the commit
git cherry-pick abc1234

This ensures you have the latest commits from the branch where your target commit lives.

4Add the remote repository if cherry-picking across repos

If the commit exists in a different repository (like a fork or upstream repo), you need to add it as a remote first.

bash
# Add the other repository as a remote
git remote add upstream https://github.com/original-owner/repo.git

# Fetch commits from that remote
git fetch upstream

# Now you can cherry-pick the commit
git cherry-pick abc1234

Example: Cherry-picking from a fork:

bash
# Add colleague's fork
git remote add colleague https://github.com/colleague/repo.git

# Fetch their branches
git fetch colleague

# Cherry-pick their commit
git cherry-pick def5678

Verify your remotes:

bash
git remote -v
5Fix commit range syntax errors

If you're cherry-picking a range of commits, ensure you're using the correct syntax.

Correct range syntax:

bash
# Cherry-pick commits from A to B (exclusive of A)
git cherry-pick A..B

# Cherry-pick commits from A to B (inclusive of A)
git cherry-pick A^..B

Common mistakes:

bash
# WRONG: Using hyphen instead of double-dot
git cherry-pick abc1234-def5678  # This won't work!

# CORRECT: Use double-dot for ranges
git cherry-pick abc1234..def5678

Cherry-pick multiple specific commits:

bash
# List commits separated by spaces
git cherry-pick abc1234 def5678 ghi9012

The A..B syntax means "commits reachable from B but not from A", which is typically what you want for cherry-picking a series.

6Handle shallow clone limitations

If your repository is a shallow clone, it may not contain the commit history you need.

Check if you have a shallow clone:

bash
git rev-parse --is-shallow-repository
# Returns "true" if shallow

Unshallow the repository:

bash
# Fetch the complete history
git fetch --unshallow

# Then retry cherry-pick
git cherry-pick abc1234

Fetch more history incrementally:

bash
# Fetch 100 more commits
git fetch --deepen=100

Shallow clones are common in CI/CD pipelines to speed up builds. If you need to cherry-pick in CI, either unshallow or adjust the clone depth:

bash
# Clone with more history
git clone --depth=100 https://github.com/user/repo.git
7Recover garbage-collected commits

If the commit was on a deleted branch, it may have been garbage collected. You have limited options:

Check if the commit is still in reflog:

bash
# Search reflogs for the commit
git reflog | grep abc1234

# Or search all reflogs
git reflog --all | grep abc1234

If found in reflog, you can still access it:

bash
git cherry-pick abc1234

If not found locally, check the remote:

The commit might still exist on GitHub/GitLab even if the branch was deleted. You can:

1. Check the PR/MR where the commit was introduced
2. Ask the colleague who made the commit to push their branch again
3. Use the GitHub/GitLab API to access the commit if it exists in any refs

Prevent future garbage collection:

bash
# Create a tag to preserve important commits
git tag preserve-abc1234 abc1234

Once garbage collected, commits cannot be recovered locally. This typically happens 30+ days after a branch is deleted.

8Use alternative methods to apply the changes

If cherry-pick continues to fail, you can apply the changes using other methods.

Create and apply a patch:

bash
# On a machine that has the commit, create a patch
git format-patch -1 abc1234

# Transfer the .patch file, then apply it
git apply 0001-commit-message.patch

# Or apply and create a commit
git am 0001-commit-message.patch

Copy changes manually using diff:

bash
# Get the diff from GitHub/GitLab and apply locally
curl -L https://github.com/user/repo/commit/abc1234.patch | git apply

For GitHub/GitLab commits:

You can append .patch to any commit URL to download it:
- GitHub: https://github.com/user/repo/commit/abc1234.patch
- GitLab: https://gitlab.com/user/repo/-/commit/abc1234.patch

Then apply:

bash
curl -L "https://github.com/user/repo/commit/abc1234.patch" | git am

Advanced notes

### Understanding Git's Distributed Model

Git is a distributed version control system where each clone is a complete repository. When you clone, you get a full copy of the history, but only for branches that existed at clone time. New commits pushed to the remote after your clone won't automatically appear in your local repository.

The command git pull is actually git fetch + git merge. If you only pull your current branch, you won't have commits from other branches. This is why git fetch --all is often necessary before cherry-picking from different branches.

### Why "Bad Revision" and Not "Commit Not Found"?

Git uses the term "revision" because the argument to cherry-pick can be:
- A commit hash (full or abbreviated)
- A branch name (resolves to the branch's HEAD commit)
- A tag name
- A relative reference like HEAD~3 or main^2

When Git says "bad revision", it means none of these lookups succeeded for the identifier you provided.

### Cherry-Pick vs Merge vs Rebase

Understanding when to use each:

| Method | Use Case | History Impact |
|--------|----------|----------------|
| cherry-pick | Copy specific commits to current branch | Creates new commits with new hashes |
| merge | Combine entire branch | Creates merge commit, preserves history |
| rebase | Replay commits on new base | Rewrites commit history |

Cherry-pick is ideal when you need only specific commits, not an entire branch. However, it creates new commits with different hashes, which can cause issues if you later merge the original branch.

### Avoiding Common Pitfalls

1. Always fetch before cherry-picking from remote branches - Make this a habit
2. Use full commit hashes when possible - Avoids ambiguity with short hashes
3. Don't cherry-pick merge commits without `-m` - Merge commits have multiple parents
4. Check for conflicts - Cherry-pick can have merge conflicts just like merge/rebase

bash
# Cherry-picking a merge commit (specify parent)
git cherry-pick -m 1 abc1234

### Git Fetch Variations

bash
# Fetch everything from all remotes
git fetch --all

# Fetch with pruning (remove deleted remote branches)
git fetch --all --prune

# Fetch tags
git fetch --tags

# Fetch specific remote
git fetch origin

# Fetch and update a local branch reference
git fetch origin main:main

Frequently asked questions

What does "fatal: bad revision 'abc1234'" mean?
When you run git cherry-pick <commit-hash>, Git attempts to locate that specific commit in your local repository's object database. The "fatal: bad revision" error means Git cannot find any object (commit, tag, or branch) matching the identifier you provided. Git stores commits locally, and your repository only knows about commits that have been fetched from remotes or created locally.
How do I fix "fatal: bad revision 'abc1234'"?
This error occurs when Git cannot find the commit you're trying to cherry-pick. The most common cause is that the commit exists on a remote branch that hasn't been fetched locally. Fetching from the remote usually resolves the issue.
What causes "fatal: bad revision 'abc1234'"?
The commit exists on a remote branch that hasn't been fetched locally The commit hash is mistyped or truncated incorrectly The commit was garbage collected after its branch was deleted
Is the "fatal: bad revision 'abc1234'" error serious?
It is a low-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading