Asked  7 Months ago    Answers:  5   Viewed   33 times

git revert <commit_hash> alone won't work. -m must be specified, and I'm pretty confused about it.

Anyone experienced this before?



The -m option specifies the parent number. This is because a merge commit has more than one parent, and Git does not know automatically which parent was the mainline, and which parent was the branch you want to un-merge.

When you view a merge commit in the output of git log, you will see its parents listed on the line that begins with Merge:

commit 8f937c683929b08379097828c8a04350b9b8e183
Merge: 8989ee0 7c6b236
Author: Ben James <>
Date:   Wed Aug 17 22:49:41 2011 +0100

Merge branch 'gh-pages'


In this situation, git revert 8f937c6 -m 1 will get you the tree as it was in 8989ee0, and git revert -m 2 will reinstate the tree as it was in 7c6b236.

To better understand the parent IDs, you can run:

git log 8989ee0 


git log 7c6b236
Tuesday, June 1, 2021
answered 7 Months ago

No you cannot force a file that is already committed in the repo to be removed just because it is added to the .gitignore

You have to git rm --cached to remove the files that you don't want in the repo. ( --cached since you probably want to keep the local copy but remove from the repo. ) So if you want to remove all the exe's from your repo do

git rm --cached /*.exe

(Note that the asterisk * is quoted from the shell - this lets git, and not the shell, expand the pathnames of files and subdirectories)

Tuesday, June 1, 2021
answered 7 Months ago

I tend to use Tower as my git client here you can see me directly reverting an older commit.

Without rewriting history:

First revert the thing you want to get rid of locally:

 git revert sha-of-2 -m X

Where X is the parent number (likely 1 in this case). See here for details.

Resolve any merge issues that come from that. Resolving these potential conflicts will make sure that 1 is applied correctly without having to revert it first. then commit and push.

The result will be:

-- 4 -- 2 -- 1 -- '2 <- master
-- 3 --/

where '2 is the inverse of 2.

With rewriting history:

WARNING: force pushing to master after rewriting history may have severe negative impact on other users of the same branch.

Do an interactive rebase:

 git rebase -i sha-of-2

drop the merge commit, keep commit 1, then force push master.

The result will be:

-- 4 -- '1 <- master

-- 3

Where '1 is a new commit with the original changes of 1 plus any conflicts you had resolved.

Rewriting history using a new branch

WARNING: force pushing to master after rewriting history may have severe negative impact on other users of the same branch.

This may be the easier to understand. It does the exact same thing as the rebase example able, but instead of applying rebase-fairy-dust, you do the hard work yourself.

Instead of rebasing you could re-do these changes yourself. Reset to 4, create a new branch, cherry pick 1, reset master to '1 and force push.

     /- '1 <- master
-- 4 -- 2 -- 1
-- 3 --/

git reset --hard sha-of-4
git checkout -B newmaster
git cherry-pick sha-of-1
# fix conflicts if any
git checkout master
git reset master --hard newmaster
git push --force

Where '1 is the cherry-picked version of 1.

Saturday, August 7, 2021
answered 4 Months ago

If you tell git to ignore a directory, it will completely ignore everything inside that directory. This means git cannot match your exclude because git is simply not looking at it.

The only way to use excludes in a meaningful way is for a single directory, where you ignore everything but some folder like this:


This will ignore all entries but foo directly under /some/path.

But, most of the time it is much clearer to just explicitly ignore things than using excludes.

Thursday, August 19, 2021
Scott Kausler
answered 4 Months ago

I have discovered a solution to this problem. It was all in the letter that Linus wrote regarding reverting faulty merges: How to revert a faulty merge. The git merge --strategy=ours topic in our case was not intended. Even though it's a faulty merge, it can't be reverted, and having long been pushed, has the same effect of having a revert merge commit without being able to revert the revert commit.

The solution was to checkout the topic branch, run rebase --no-ff from the first commit and then merge that branch back into master.

git checkout topic
git rebase -i --no-ff <C>
git checkout master
git merge topic

This had the effect of yielding:

fixed–topic   C'–––D'––––––––––––––––––––-
master  A–––B–––E–––F–––G –––> L–––M–––N–––F2
topic         C–––D

To really understand this in-depth, read the last portion of the letter How to Revert a Faulty Merge using the --no-ff rebase option to re-create the branch.

Sunday, October 31, 2021
Platinum Azure
answered 1 Month ago
Only authorized users can answer the question. Please sign in first, or register a free account.
Not the answer you're looking for? Browse other questions tagged :