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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html