The revert of a merge is confusing, because it does not do exactly what you think.
If you have this story:
H
--o--o--o--M--o--o
/
---A--B
Where H is HEAD (say for example of the master branch) and M is the commit in which you made merge, and in that situation you make a git revert -m1 M , it does not get undone the merge as if it had never been done, but a new commit is added to the master branch, but a commit whose changes are the opposite of those introduced by M . Call it W
H
--o--o--o--M--o--o--W
/
---A--B
That is, if for example, as a consequence of the merge M a file has a pair of lines added, as a consequence of the revert W that pair of lines will be deleted.
In other words, commit W introduces changes in your story, but they are changes such that all your files are in an identical state to the one they had in the previous commit to M , plus the changes introduced by commits after M . Equivalent to edit those files by hand, correct the changes that had been introduced in the merge, and then make a add and a commit of those changes. They change the files, but it does not change the history of the graph, where we can see that the merge is still there (and therefore you can not do it again).
Depending on what happened from the point I show in the previous figure (have you continued committing in the master branch? Have you continued making commits in the branch where A and B were?) the solution to fix the mess can be different.
You can read more details (from Linus Torwalds himself) here: How to revert to faulty merge (from where I have "plagiarized" the figures). Or edit your question to add extra information that allows me to help you.
Update
The user confirms that the original branch ( ---A--B in the figure) has not changed, but the master branch. The current situation I understand would be something like this:
H
--o--o--o--M--o--o--W--x--x
/
---A--B
where x would be the new commits in master.
It can be assumed that these x have somehow fixed the problem that prevented the merge in M was not valid, so we want to do that merge again, but we can not because it is done.
One solution is to make a revert commit that the revert had done. It may sound like tongue twisters, but the idea is:
git revert W
and the thing would be left now:
H
--o--o--o--M--o--o--W--x--x--N
/
---A--B
So the changes that the commit W introduced are applied "upside down" in the commit N . Thus, following the aforementioned example, if the merge M had caused two new lines in a file, in the first revert W the file was deleted those two lines and this new revert ( N ) will add again those two lines to the file.
Of course this can cause conflict if the files "restored" in W have been modified incompatible in any of the x , but this is something that is solved in the known way (conflicting files are edited , they are added with git add and the revert is completed with git commit )