title: How to fix bad conflict resolution in the middle of a big git rebase?
body: <p>I’m trying to rebase a feature branch with a lot (~300) of commits onto a newer major release version of the base product. Right in the middle of the rebase with many conflicts already resolved, I notice that some files still contain conflict markers (“&lt;&lt;&lt;&lt;&lt;&lt;&lt;”), even though no more conflicting files are listed in <code>git status</code>. I guess that I missed them in some earlier commit, mistakenly marking the files as resolved, even though they weren’t.</p>
  
  <p>Is there a way to fix mistakes in earlier commits in the middle of an ongoing rebase, and continuing the rebase afterwards?</p>
  
  <p>I don’t want to <code>--abort</code> the rebase, because I would lose many hours of conflict resolution work.</p>
  
  <p>I don’t want to ignore the problem, by just fixing the conflict markers in the commit I’m currently in. This way the intermediate commits would be invalid and non-compiling.</p>
  
  <p>I have already made a backup copy of my working directory, so I can experiment.</p>
  
  <p>If there’s no easier way, my backup plan would be to finish the rebase as it is and try to clean up the history afterwards. I would remove the conflict markers in the current commit and note its ID. After the rebase is finished, I would try to find the earlier commits which introduced the conflict markers with some pickaxe magic and then try to clean up the history in another <code>git rebase -i</code>. Do you think this route is feasible?</p>
  
  <p>I’ve used Eclipse egit so far, in case it matters, but would switch to the commandline for advanced stuff.</p>