title: How do I use `git rebase -i` after `git merge` without messing things up?
body: <p>I have the following situation:</p>
  <ol>
  <li><p>I made some commits to my local repository, and then a huge merge of another branch (~150 commits) into the master. It had a lot of conflicts in it.</p>
  </li>
  <li><p>Now, I want to move a commit I made before the merge to be after it before pushing.</p>
  </li>
  </ol>
  <p>Normally, I would use <code>rebase -i</code> for it.</p>
  <p>Unfortunately, the default behavior is to break the one-merge-commit I did that actually added 150 more commits to master into separate commits (I understand it's like if I were to use rebase instead of merge to begin with)—which is bad behavior for me for several reasons.</p>
  <p>I was very happy to discover the <code>-p</code> flag for rebase, which preserves merges.
  Unfortunately, this actually applied the same merge again and forgot all about my hard work in conflict resolving. Again—bad behavior!</p>
  <p>Is there a solution for what I want? Using <code>rebase -i</code> after merge to re-order or edit specific commits without having to repeat my post-merge operations?</p>
  <p>Thanks!</p>