On 12-06-14 02:57 AM, Matthieu Moy wrote: > Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> writes: > >>> Shouldn't "rebase --continue" after such a "commit --amend" resume >>> execution from "exec cmd1", which failed in the initial run? +1 for Junio's proposal. Currently the only time --continue moves on to the next insn is in the "edit" case, when everything up to that point (including applying the "edit" commit) is fine. But if the rebase halted due to a problem, --continue ensures the problem is fixed before moving on to the next insn (e.g. it makes sure a merge conflict is resolved). I think it makes the most sense for --continue after an exec-failure to try to re-run the exec. Furthermore, --skip after an exec failure should just skip the exec. To me that makes --continue's (and --skip's) behaviour consistent with what it does when any other insn operation fails. In other words, if the rebase hits an exec failure, the user is going to want to fix it before continuing (just like any other failure during a rebase). If the user decides to not fix the failing exec, they can --skip it. M. -- 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