[BUG?] rebase -i: edit versus unmerged changes

Hi,

I have the following instruction sheet:

  pick 2f7c86e remote.c: simplify a bit of code using git_config_string()
  pick c7f7ae4 remote.c: introduce a way to have different remotes for
fetch/push
  edit 7038841 remote.c: introduce remote.pushdefault
  edit 73413b0 remote.c: introduce branch.<name>.pushremote
  pick 7f47687 WIP: fetch-push: write a test

When I get to 7038841, I edit config.txt, stage the changes and commit --amend, before executing rebase --continue. When I get to 73413b0 (the next commit), I get a conflict which is auto-resolved by rerere. So, I just make further changes to config.txt, and commit --amend before executing rebase --continue as before. Unfortunately, this squashes 73413b0 into 7038841, because the merge conflict requires a commit to resolve the merge and pick the commit; this is different from commit --amend, which worked in the previous case, because the commit was already picked.

I know that this is expected behavior, but is there an easy way to get rid of this inconsistency? I'd ideally like everything to use the sequencer, and have uniform --continue/ --abort/ --skip semantics, but that would require re-implementing all the shell commands in C unless we can think of exposing a generic API using stdin or something. Does anyone have ideas in this direction?

Thanks.

Ram