1

git overlords, listen to my pleas:

I have a git branch, call it "master" (original, I know). Now, I've also been working on two other branches, call them "dammit" and "mistake", simultaneously. When I was done, both branches were merged into "master", and then to production.

Problem is, I suspect some changes made in those branches were detrimental (why I think that is irrelevant), so I wanted to revert back to a specific commit made somewhere between when I started working on the side branches ("mistake" and "dammit". So, say I started working on them Aug 1st and merged Aug 10th, I want to go back to Aug 3rd). However, it seems if I revert back to August 3rd, the commits made on the side branches before that date are still going to be on my "master".

Is there some kind of 'git revert' wizardry I can use in order to make this happen? Some git command I'm not aware of?

Perhaps some changes to git rev-list --parents -n 1 <commit> ? That's not really what I want, then again I can't call myself a git expert.

I can't be the only one to ever experience this problem (though searching SO might give that impression).

Help?

ckruczek
  • 2,361
  • 2
  • 20
  • 23
CodeBender
  • 67
  • 9

1 Answers1

0

However, it seems if I revert back to August 3rd, the commits made on the side branches before that date are still going to be on my "master".

That's the expected behavior. git revert is not 'resetting' some commits it basically takes the negative snapshot of the commit you revert and creates a new commit.

If you really want to get rid of the mistaken git merge. You have to do a git reset. But be aware! git reset is a command that rewrites history. So if your history is a public one, with more than one contributer you will get into troubles after pushing the rewritten history. If not, you can safely do a 

git reset --hard <commitIDOfTheComitFrom3rdAugust>

and then after you fixed everything you have to 

git push --force origin <whatever>
ckruczek
  • 2,361
  • 2
  • 20
  • 23
  • question is, wouldn't reseting to the commit from August 3rd leave remnants from the merged branches, that were committed prior to that specific commit? I saw some references here: http://stackoverflow.com/questions/2389361/undo-a-git-merge stating I should "mark" the main branch. Sounds to me like half the solution. Or am I missing something? – CodeBender Aug 18 '15 at 12:00
  • Imagine you have the following [graph](http://jsfiddle.net/guan1oz1/184/). Reseting `master` hard to the third gray commit would 'forget' about all the other commit in between, escpially the merged one. – ckruczek Aug 18 '15 at 12:05
  • Ha, cool library, I'll use it the next time I have a question :) So yes, that would definitely be the case for the third node from the left. But what if I want to go back to the third node from the right (say the first blue node from the left was made August 1st)? – CodeBender Aug 18 '15 at 12:11
  • 1
    Heheh yes. Ok so you want reset the blue path lets call it `branch damnit` to the first blue node. Then you have to checkout the `damnit` and reset it hard to the first blue node. – ckruczek Aug 18 '15 at 12:14
  • Indeed, that would work if I only had those 2 branches to worry about. unfortunately this is a shared repo and we have more than 20 merged branches we need to revert, which is why I was hoping to find some sort of a shortcut. – CodeBender Aug 18 '15 at 12:26
  • Well if it shared, then `git reset` is not applicable and you have to go with `git revert` – ckruczek Aug 18 '15 at 12:35
  • That's what I suspected, but a regular call to `git revert -m ` results in those side branches earlier commits still being present in my "master". I'm making some kind of rookie mistake, just not sure which. – CodeBender Aug 18 '15 at 12:43
  • Let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/87272/discussion-between-ckruczek-and-codebender). – ckruczek Aug 18 '15 at 12:55