Git revert -m selects a parent baseline, not a branch to remove

By ON Lab · Sources checked November 8, 2026

For a merge commit, git revert -m N selects parent N as the baseline and reverses the merge's change relative to that parent. N is a one-based position in the commit's recorded parent list. It is not the number of a branch to delete. A three-parent merge can therefore lose the changes from two other parents when reverted relative to the third.

A historical reader showed an octopus merge and asked why -m 3 removed two branches' files. We checked current Git documentation and created a separate three-parent fixture with independent added files. This explains that operation's meaning without accessing the reader's original commit objects or promising that every merge can revert without conflicts.

Read the parents that the commit actually records

git status --short
git show --no-patch --format='%H%n%P%n%s' MERGE_COMMIT

Replace MERGE_COMMIT with the verified commit ID. The second line prints its parent IDs in order. The first parent is position 1, the next is 2, and so on. Do not guess the number from the current branch list, the names in the merge subject, or which branch you want removed. Branch pointers can move or disappear after the merge while the commit's parent order stays recorded.

A regular two-parent merge often has the pre-merge current branch as parent 1. Inspect rather than generalizing that convention to every graph. An octopus merge may have more than two parents; our actual merge fast-forwarded to the first topic and recorded three topic parents. The original base was not an additional fourth parent.

Compare the baseline before reversing it

git diff --stat 'MERGE_COMMIT^1' MERGE_COMMIT
git diff --stat 'MERGE_COMMIT^2' MERGE_COMMIT
git diff --stat 'MERGE_COMMIT^3' MERGE_COMMIT

These read-only comparisons show the changes going from each chosen parent to the merge. Revert attempts the reverse of that relative change on your current history. Inspect the complete relevant diff after the summary, especially if the merge includes conflict resolutions or overlapping edits. A parent number alone is not a review of the patch.

Choose the parent whose perspective should be kept as the baseline for undoing this merge. That does not mean Git deletes the other commits or erases the merge from history. A successful revert normally creates a new commit with inverse changes. Later work on your current branch can make that inverse patch conflict or produce a result requiring additional review.

What our three-parent reproduction showed

In a disposable repository we committed base.txt, then made three branches from that base. Each branch independently added one file: one.txt, two.txt or three.txt. We merged all three from the main branch, inspected the actual parent list, and created a separate revert branch from the merge for each choice.

Selected baseline	Files remaining after revert	Tree comparison
Parent 1	base.txt and one.txt	Equal to parent 1's tree
Parent 2	base.txt and two.txt	Equal to parent 2's tree
Parent 3	base.txt and three.txt	Equal to parent 3's tree

The third choice removed one.txt and two.txt together. Both were additions relative to the third parent's tree. It did not mean “remove the third branch.” We compared tree IDs, not just the command's success message or a visual file count.

Exact equality to the chosen parent's tree was possible because our revert began directly at the clean merge, the files were independent, and there were no subsequent changes. Treat it as a controlled demonstration, not a general guarantee for a production branch with later commits.

Try the reviewed choice on a disposable branch

git switch -c review-merge-revert
git revert --no-edit -m 3 MERGE_COMMIT
git show --stat HEAD
git diff HEAD^ HEAD
git status --short

This example assumes parent 3 was already reviewed and is the intended baseline. It is not a recommendation to use 3 for your merge. Begin with a clean working tree and an unused review-branch name. Inspect the new commit's full patch and run the project's relevant tests before sharing the branch.

If conflicts occur, read each conflicted change against the intended baseline. Continue only after a reviewed resolution. Git documents git revert --abort for abandoning an active revert sequence; it is not a command for undoing an already completed revert commit. Preserve unrelated work before any corrective operation and do not substitute a hard reset for understanding the state.

Reverting changes also affects future merge expectations

The merge commit remains an ancestor. Git's documentation warns that a later merge brings changes from commits outside the ancestry already merged and reverted; it does not simply replay the same original tree changes because the branch is merged again. If you intend to reintroduce that work later, review the documented faulty-merge workflow and the real graph before choosing an operation.

Our fixture did not test re-merging, conflicts or shared remote history. This warning is a documented behavior boundary, not a prediction of your next merge's exact patch. Reverting a revert or reworking the topic can have different consequences that need their own review.

Completion checklist

Confirm the exact merge commit and actual ordered parent IDs.
Compare the merge to each plausible parent and choose the intended baseline.
Test the revert on a separate clean branch.
Read the full resulting patch and run meaningful project checks.
Record why that baseline was chosen and whether the work should return later.

Checked November 8, 2026. A local Git fixture verified all three parent choices and tree IDs. It did not reproduce the reader's repository, test a later remerge, or measure present search demand.