[BUG?] git-revert ignores --no-commit on conflicts

Hi,

I found something which seems to be a bug to me (or well, maybe I'm doing something wrong...). When I revert a commit with -n/--no-commit and there's a conflict, when doing "git revert --continue" I get an editor, even though I wouldn't expect that to happen.

Example:

    $ git init
    Initialized empty Git repository in [...]
    $ echo foo > file
    $ git add file
    $ git commit -m "Initial commit"
    [master (root-commit) 9f8e5fb] Initial commit
     1 file changed, 1 insertion(+)
     create mode 100644 file
    $ echo bar > file
    $ git commit -am "foo -> bar"
    [master e53d99f] foo -> bar
     1 file changed, 1 insertion(+), 1 deletion(-)
    $ echo baz > file
    $ git commit -am "bar -> baz"
    [master fa3c23f] bar -> baz
     1 file changed, 1 insertion(+), 1 deletion(-)
    $ git revert -n HEAD  # this works as expected
    $ git revert --abort
    $ git revert -n e53d99f  # reverting the middle commit to provoke a conflict
    error: could not revert e53d99f... foo -> bar
    hint: after resolving the conflicts, mark the corrected paths
    hint: with 'git add <paths>' or 'git rm <paths>'
    $ echo fish > file
    $ git add file
    $ git revert --continue  # here my editor opens
    Aborting commit due to empty commit message.

Tested using git 1.9.1 and 1.9.0.msysgit.0.

Florian