This error appears when you try to cherry-pick a merge commit. Merge commits have two (or more) parents, and Git does not know which parent to use as the baseline for computing the diff. The fix is to specify the parent with the -m flag: git cherry-pick -m 1 <commit>. In most cases, -m 1 is correct because parent 1 is the branch that received the merge.

Why Merge Commits Are Different

A regular commit has exactly one parent. When you cherry-pick it, Git computes the diff between that commit and its single parent, then applies that diff to your current branch. There is no ambiguity.

A merge commit has at least two parents. It represents the point where two branches were joined. The "changes" introduced by a merge commit depend entirely on which parent you compare against:

• Compared to parent 1 (the branch that ran git merge), you see everything the merged branch contributed.
• Compared to parent 2 (the branch that was merged in), you see everything the receiving branch had that the merged branch did not.

These are completely different diffs. Git refuses to guess, so it requires you to specify the parent explicitly.

Inspecting the Merge Commit

Before choosing a parent number, inspect the commit to understand its structure:

1# Show the merge commit with parent SHAs
2git show --no-patch --format="%H%n%P%nParent 1: %p" 38c74d
3
4# Or see the raw commit object
5git cat-file -p 38c74d

The output will include lines like:

parent a1b2c3d4e5f6...
parent f6e5d4c3b2a1...

The first parent line is parent 1, the second is parent 2. You can also visualize the context:

# Show the merge in graph form
git log --oneline --graph --decorate 38c74d~5..38c74d

Using -m to Specify the Parent

The -m flag (short for "mainline") tells Git which parent to treat as the baseline:

1# Replay changes from the merged branch (relative to the receiving branch)
2git cherry-pick -m 1 38c74d
3
4# Replay changes from the receiving branch (relative to the merged branch)
5git cherry-pick -m 2 38c74d

When to Use -m 1 vs. -m 2

In the vast majority of cases, you want -m 1 because you are trying to bring in the changes that were introduced by the branch that was merged in.

Step-by-Step Workflow

Here is the complete workflow for cherry-picking a merge commit safely:

1# 1. Identify the merge commit and its parents
2git log --oneline --graph 38c74d~3..38c74d
3
4# 2. Inspect what each parent comparison produces
5git diff 38c74d^1..38c74d --stat   # changes relative to parent 1
6git diff 38c74d^2..38c74d --stat   # changes relative to parent 2
7
8# 3. Create a safety branch (recommended for shared repos)
9git checkout -b cherry-pick-attempt
10
11# 4. Cherry-pick with the correct parent
12git cherry-pick -m 1 38c74d
13
14# 5. Verify the result
15git show --stat HEAD
16git diff HEAD~1..HEAD
17
18# 6. If the result is wrong, abort and try the other parent
19git cherry-pick --abort
20git cherry-pick -m 2 38c74d

Handling Conflicts

Cherry-picking merge commits often produces more conflicts than cherry-picking regular commits because the diff can be large and the branch context is different. When conflicts occur:

1# See which files have conflicts
2git status
3
4# Resolve conflicts in each file, then mark as resolved
5git add path/to/resolved_file.java
6git add path/to/another_file.py
7
8# Continue the cherry-pick
9git cherry-pick --continue
10
11# Or abort if conflicts are too complex
12git cherry-pick --abort

If conflicts are extensive, consider the alternative approach of cherry-picking individual non-merge commits instead.

Alternative: Cherry-Pick Individual Commits

Often, cherry-picking the merge commit itself is not the best approach. If the merged branch contains 5 commits, you can cherry-pick each one individually:

1# List commits from the merged branch
2git log --oneline 38c74d^1..38c74d^2
3
4# Cherry-pick specific commits
5git cherry-pick abc1234
6git cherry-pick def5678
7git cherry-pick 789abcd

This approach has several advantages:

The individual commit approach is especially useful when you only need some of the changes from the merged branch, or when you are backporting to a release branch with divergent history.

Reverting a Merge Commit

The same -m flag applies to git revert for merge commits:

# Revert a merge commit (undo the merge)
git revert -m 1 38c74d

This creates a new commit that undoes the changes introduced by the merged branch. Be aware that after reverting a merge, re-merging the same branch later requires extra steps because Git considers those commits already merged.

Using --no-commit for Review

If you want to inspect the cherry-picked changes before committing them, use --no-commit:

1git cherry-pick -m 1 --no-commit 38c74d
2
3# Review the staged changes
4git diff --staged
5git diff --staged --stat
6
7# If satisfied, commit manually
8git commit -m "Cherry-pick feature X from merge 38c74d"
9
10# If not satisfied, reset
11git reset --hard HEAD

Safe Workflow for Shared Repositories

When working on shared branches like release or main, always cherry-pick on a temporary branch first:

1# Create a temporary branch from the target
2git checkout release/2.1
3git checkout -b cp-feature-x
4
5# Cherry-pick on the temporary branch
6git cherry-pick -m 1 38c74d
7
8# Run tests
9./gradlew test
10
11# If everything passes, open a PR from cp-feature-x to release/2.1

This keeps the risky operation isolated and reviewable. If something goes wrong, you can delete the temporary branch without affecting the release branch.

Common Pitfalls

Forgetting the -m flag entirely. This produces the error message you are reading about. Every merge commit cherry-pick requires -m.

Choosing the wrong parent number. Using -m 2 when you meant -m 1 gives you the inverse set of changes. Always inspect the diff with git diff 38c74d^1..38c74d --stat before committing.

Assuming the cherry-picked result matches the original merge exactly. The cherry-pick replays a diff onto a different base. Files that were modified differently on your current branch will conflict or produce different merge results.

Cherry-picking a merge that includes many unrelated changes. If the merge commit bundles multiple features (for example, merging a long-lived develop branch), cherry-picking the whole thing brings all of those changes. Pick individual commits instead.

Not testing after the cherry-pick. The cherry-pick may apply cleanly but still break the build because of missing dependencies that were introduced in other commits from the merged branch.

Reverting a merge and then trying to re-merge. After git revert -m 1 <merge>, Git treats the original commits as already integrated. To re-merge, you need to revert the revert first: git revert <revert-commit>.

Summary

When Git says a commit "is a merge but no -m option was given," it needs you to specify which parent to use as the diff baseline. Use git cherry-pick -m 1 <commit> for the most common case where parent 1 is the receiving branch. Always inspect the commit's parents and the resulting diff before pushing. For complex merges, prefer cherry-picking individual non-merge commits from the feature branch. Work on temporary branches when cherry-picking onto shared branches to keep the operation safe and reviewable.