How to fix error: commit abc1234 is a merge but no -m option was given in Git

GitINTERMEDIATELOWUpdated Dec 6, 2025· 174 views

This error occurs when cherry-picking a merge commit without specifying which parent to use as the base. Use the -m option to specify the parent number (typically -m 1 for the main branch).

Quick fix

Fixes error: commit abc1234 is a merge but no -m option was given

git show --pretty=raw <commit-hash>
  1. Identify if the commit is a merge commit
  2. Understand which parent to use
  3. Cherry-pick with the -m option
  4. Handle conflicts if they arise
git — error
git show --pretty=raw <commit-hash>
error: commit abc1234 is a merge but no -m option was given

What this error means

When you run `git cherry-pick` on a merge commit, Git doesn't know which side of the merge should be considered the "mainline" or base. Unlike regular commits that have a single parent, merge commits have two or more parents representing different lines of development. Cherry-picking works by calculating the diff between a commit and its parent, then applying that diff to your current branch. With a merge commit, there are multiple parents to choose from, and each choice produces a different set of changes. For example, if you merged a feature branch into main, parent 1 would be the main branch and parent 2 would be the feature branch. Git requires you to explicitly specify which parent to use via the `-m` option. Using `-m 1` tells Git to treat the first parent as the base and apply the changes that came from the second parent (typically the merged branch). Using `-m 2` would do the opposite—it applies changes that existed in the first parent but not in the second.

Typical symptoms

  • Cherry-pick command fails immediately with 'is a merge but no -m option was given'
  • Attempting to backport a merged pull request or merge request fails
  • Git revert on a merge commit shows the same error
  • CI/CD pipelines fail when automatically cherry-picking merged commits
  • The commit hash in the error message corresponds to a merge commit in git log

Common causes

  1. Cherry-picking a merge commit without the -m flag (most common)
  2. Attempting to cherry-pick a pull request merge commit instead of the individual feature commits
  3. Scripted cherry-pick operations that don't handle merge commits specially
  4. Reverting a merge commit without specifying the parent (git revert has the same requirement)
  5. Using GUI tools that don't expose the -m option for merge commits
  6. Misidentifying a merge commit as a regular commit

How to fix "error: commit abc1234 is a merge but no -m option was given"

1Identify if the commit is a merge commit

First, verify that the commit you're trying to cherry-pick is indeed a merge commit:

bash
git show --pretty=raw <commit-hash>

Look for a line starting with Merge: which shows the parent commit hashes. For example:

bash
commit abc1234...
Merge: def5678 ghi9012

If you see two or more parent hashes, it's a merge commit and requires the -m option.

2Understand which parent to use

The parent number determines which changes get applied:

- Parent 1 (-m 1): Usually the branch being merged INTO (e.g., main/master)
- Parent 2 (-m 2): Usually the branch being merged FROM (e.g., feature branch)

To see what each parent represents:

bash
git log --oneline -1 <parent1-hash>
git log --oneline -1 <parent2-hash>

In most cases, you want -m 1 because you want to apply the changes that were introduced by the feature branch (the diff between parent 1 and the merge).

3Cherry-pick with the -m option

Run the cherry-pick with the appropriate parent number:

bash
git cherry-pick -m 1 <merge-commit-hash>

This tells Git to use the first parent as the base and apply the changes from the merged branch.

If you want the opposite (apply changes from the first parent's perspective):

bash
git cherry-pick -m 2 <merge-commit-hash>
4Handle conflicts if they arise

If conflicts occur during the cherry-pick, resolve them as usual:

bash
# See which files have conflicts
git status

# Edit conflicted files to resolve
# Then mark them as resolved
git add <resolved-file>

# Continue the cherry-pick
git cherry-pick --continue

Or abort if needed:

bash
git cherry-pick --abort
5Alternative: Cherry-pick individual commits instead

Often a better approach is to cherry-pick the individual commits from the merged branch rather than the merge commit itself:

bash
# Find commits in the merged branch
git log --oneline <parent1>..<parent2>

# Cherry-pick each commit individually
git cherry-pick <commit1> <commit2> <commit3>

Or cherry-pick a range:

bash
git cherry-pick <oldest-commit>^..<newest-commit>

This preserves the original commit structure and history.

6For git revert on merge commits

The same -m option applies when reverting merge commits:

bash
git revert -m 1 <merge-commit-hash>

This creates a new commit that undoes the changes introduced by the merge. Use -m 1 to revert the changes that came from the merged branch while keeping the mainline changes.

7Verify the result

After a successful cherry-pick, verify the changes are correct:

bash
# View the new commit
git log -1 --stat

# Compare with expected changes
git diff HEAD~1

# Run tests to ensure the cherry-picked changes work

Note that cherry-picking a merge commit creates a single commit containing all the squashed changes, losing the individual commit history from the original branch.

Advanced notes

### Understanding Parent Order

When you run git merge feature-branch while on main:
- Parent 1 = the commit that was HEAD on main before the merge
- Parent 2 = the tip of feature-branch

The merge commit represents a tree that combines both parents. The Merge: line in git show displays parents in order (parent1 parent2).

### Warning: Loss of History

When you cherry-pick a merge commit with -m 1, you're collapsing all the changes from the merged branch into a single commit. You lose:
- Individual commit messages
- Commit authorship information
- Bisect-ability of those changes

If preserving history matters, cherry-pick the individual commits instead.

### Octopus Merges

For octopus merges (merging more than two branches), you can specify any parent number (-m 1, -m 2, -m 3, etc.). The order follows how they were specified in the merge command.

### Scripting Considerations

When scripting cherry-picks, check if a commit is a merge before attempting:

bash
if git rev-parse --verify ${commit}^2 >/dev/null 2>&1; then
  # It's a merge commit, use -m 1
  git cherry-pick -m 1 ${commit}
else
  # Regular commit
  git cherry-pick ${commit}
fi

### GUI Tool Workarounds

Many Git GUIs (SourceTree, GitKraken, VS Code) don't expose the -m option. Use the command line for cherry-picking merge commits, or cherry-pick the individual commits from the branch instead.

Frequently asked questions

What does "error: commit abc1234 is a merge but no -m option was given" mean?
When you run git cherry-pick on a merge commit, Git doesn't know which side of the merge should be considered the "mainline" or base. Unlike regular commits that have a single parent, merge commits have two or more parents representing different lines of development. Cherry-picking works by calculating the diff between a commit and its parent, then applying that diff to your current branch.
How do I fix "error: commit abc1234 is a merge but no -m option was given"?
This error occurs when cherry-picking a merge commit without specifying which parent to use as the base. Use the -m option to specify the parent number (typically -m 1 for the main branch).
What causes "error: commit abc1234 is a merge but no -m option was given"?
Cherry-picking a merge commit without the -m flag (most common) Attempting to cherry-pick a pull request merge commit instead of the individual feature commits Scripted cherry-pick operations that don't handle merge commits specially
Is the "error: commit abc1234 is a merge but no -m option was given" error serious?
It is a low-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading