After fixing conflicts git still complains?

I agree with Mark Rushakoff that fixing commits should not include committing them.

There is at least one other way that git will continue to say that "You must edit all merge conflicts and then mark them as resolved using git add" even after you have done just this. This may occur if you remove files from git version control, but leave the unversioned file sitting in your working tree and then try to perform a rebase.

I was able to fix this problem as follows:

1. Terminate rebase with git rebase --abort
2. Determine offending file by looking at git status
3. I moved my unversioned files to my tmp directory
4. Redo the rebase - in my case git svn rebase
5. If you want the unversioned file hanging around, move it back where you want it (I left mine in my tmp directory)

Hope that helps.

When this happened to me, I managed to solve it after realizing I had edited (and added to the index) during the rebase a file which does not have a conflict, I guessed this might be wrong. So I used git checkout -- <filename-with-no-conflict>, and then git rebase --continue, and it worked.

So after opening each file with a conflict, fixing it then committing the fixed files...

The problem is that you aren't supposed to commit the fixes. If a.txt has a merge conflict, then your shell log should look like:

$ vim a.txt # fix conflict
$ git add a.txt
$ # no commit between add and rebase!
$ git rebase --continue

Calling git rebase --continue will take care of the commit itself.

I'm not sure how to "get back" to before your commit, when you're in the middle of a rebase. git reset --hard HEAD would probably do the trick, but personally I'd feel safer just going straight to git rebase --abort and starting over without committing in the middle.