This is not a problem that --reset
will fix. The OP's issue is that he merged a branch, then used git revert
to revert the effect of the the merge. git revert
introduces a NEW set of commits that reverse the effect of the reverted commits, leaving the original commits in the branch.
This is a problem if you then try to re-merge the same branch again. The commits already exist in your target branch (even though they've been nullified by the later reversion), and so git merge
refuses to merge them a second time - they're already there.
However, if your commits on the branch that you want to merge in had new hashes, they'd appear to be new commits and would merge as desired. There are a couple ways to accomplish that. For instance, git cherry-pick
actually creates NEW commits with new hashes. You can make a new branch, cherry-pick the commits you want onto that, and then merge that to master.
Cherry-picking multiple commits: How to cherry-pick multiple commits
For more details (including the official solution, rather than my rather hackish one): Re-doing a reverted merge in Git