This error occurs when you try to revert a merge commit without specifying which parent to use. Git requires the -m option to determine which branch's changes to undo.
When you attempt to revert a merge commit using `git revert <commit>`, Git refuses because merge commits have two parent commits, not one. A regular commit has a single parent, so Git knows exactly what changes to undo. But a merge commit represents the joining of two branches, each with their own history. Git needs you to tell it which parent to treat as the "mainline" - the branch you want to keep as-is. The other parent's changes will be reverted. This is what the `-m` (or `--mainline`) option does: it specifies the parent number (1 or 2) that represents the original branch you merged into. For example, if you merged a feature branch into main, parent 1 is typically the main branch (the branch you were on when you ran `git merge`), and parent 2 is the feature branch. Using `git revert -m 1 <merge-commit>` keeps main's history and reverts the feature branch's changes.
First, confirm the commit you want to revert is actually a merge commit:
git log --oneline <commit-hash> -1If it's a merge, you'll see something like:
abc1234 Merge branch 'feature-x' into mainTo see the parent commits:
git cat-file -p <commit-hash>This shows both parents. The first listed is parent 1, the second is parent 2.
The parent number determines which branch's state Git reverts to:
- Parent 1 (-m 1): The branch you were on when you ran git merge. Usually main/master.
- Parent 2 (-m 2): The branch that was merged in. Usually your feature branch.
You can visualize this with:
git log --graph --oneline <commit-hash>^1 <commit-hash>^2 -5Or check the merge commit message which typically says "Merge branch 'X' into Y" - Y is parent 1, X is parent 2.
In most cases, you want to undo the feature branch changes while keeping main's history. Use:
git revert -m 1 <merge-commit-hash>This creates a new commit that undoes all changes brought in by the merged branch.
Example:
git revert -m 1 abc1234Git will open your editor for the commit message. The default message explains what was reverted.
Git generates a default commit message like:
Revert "Merge branch 'feature-x' into main"
This reverts commit abc1234, reversing
changes made to 8989ee0.You can:
- Accept the default message by saving and closing the editor
- Customize it to explain why you're reverting
- Use --no-edit to skip the editor: git revert -m 1 --no-edit <hash>
After the revert, confirm the changes were undone:
# See what changed
git diff HEAD~1
# Check the log
git log --oneline -3
# Verify specific files are restored
git show HEAD --statThe reverted files should now match their state before the merge.
Once you've verified the revert is correct, push it:
git push origin <branch-name>Important: Unlike git reset, this creates a new commit rather than rewriting history, so it's safe to push to shared branches.
Critical caveat: After reverting a merge, you cannot simply re-merge the same branch later. Git sees those commits as already merged.
To re-merge the feature branch later, you must first revert the revert:
# Find the revert commit
git log --oneline | grep "Revert"
# Revert the revert
git revert <revert-commit-hash>
# Now you can merge again (or the original changes are back)
git merge feature-branch # if there are new commitsIf you haven't pushed the merge yet, git reset is simpler:
# Undo the merge entirely (moves HEAD back)
git reset --hard HEAD^
# Or keep changes in working directory
git reset --soft HEAD^Warning: Only use git reset on commits you haven't shared with others. It rewrites history.
### Choosing Between -m 1 and -m 2
The choice of parent affects what the repository looks like after the revert:
- -m 1: Keeps the state of the target branch (where you merged into), undoes the source branch changes
- -m 2: Keeps the source branch changes, undoes the target branch's changes since the merge base
Almost always, you want -m 1 because you're undoing a feature that was merged in, not undoing your main branch.
### The "Revert of Revert" Problem
When you revert a merge, Git records that those commits were "merged and then undone." If you later try to merge the same branch again, Git won't bring in the old commits because it thinks they're already incorporated.
Solutions:
1. Revert the revert before re-merging (creates clean history)
2. Cherry-pick the specific commits you need instead of merging
3. Rebase the feature branch to create new commit hashes (more complex)
### Reverting Multiple Merge Commits
If you need to revert multiple merge commits, revert them in reverse chronological order:
git revert -m 1 <newest-merge>
git revert -m 1 <older-merge>
git revert -m 1 <oldest-merge>### Merge Commits in Git Bisect
When bisecting and you hit a merge commit, you may need to specify which parent to follow. Use:
git bisect good <merge-commit>^1
# or
git bisect bad <merge-commit>^2### GUI Tools
Some GUI tools hide the complexity:
- GitKraken: Right-click merge commit > Revert (handles -m automatically)
- SourceTree: May require manual intervention for merge reverts
- VS Code GitLens: Shows both parents, lets you choose
warning: BOM detected in file, this may cause issues
UTF-8 Byte Order Mark (BOM) detected in file
fatal: Server does not support --shallow-exclude
Server does not support --shallow-exclude
warning: filtering out blobs larger than limit
Git partial clone filtering large blobs warning
fatal: Server does not support --shallow-since
Server does not support --shallow-since in Git
kex_exchange_identification: Connection closed by remote host
Connection closed by remote host when connecting to Git server