Reverting a range of commits with conflict

Given:
    A-B-C-D-E (HEAD)
I want to create a single commit that reverts A-B-C

So, I execute:
    git revert --no-commit A~..C
which causes conflict (while reverting C, it seems).

I resolve conflicts and I continue:
    git revert --continue --no-commit
And, it complains:
    fatal: revert: --no-commit cannot be used with --continue

If I revert --continue without --no-commit:
    git revert --continue

It brings up EDITOR twice and I end up with two commits. I can squash them. But, I don't know if this is a desired behavior.

Should I be able to revert --continue with --no-commit? Should revert --continue remember that initial revert invocation was with --no-commit option?

Thanks.

Sam Lee <skynare@gmail.com> writes:

It is my understanding that the users who do want a single revert of multiple commits are expected to squash them (by choosing which ones to squash into one), so if you really want to make them into one, you can squash them and that is your desired behaviour. The point is that you do not have to.

If you think a bit about it, it does not make much sense to leave outstanding changes in limbo with --no-commit when you are picking or reverting multiple commits. The first one may replay cleanly or may not and needs manual resolution, but after that, the work you did will only be in your working tree, and the difference between that and the HEAD and the index is not recorded anywhere else. What happens when the replaying (either cherry-picking or reverting) of the second one had conflict? The effect of picking or reverting the first one is now intermingled with the effect of the conflicted picking or reverting of the second---with --no-commit, the workflow is making the messy conflicted state needlessly larger.