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? There are use-cases where this would be useful, but that would also be a real pain if the command itself is broken (e.g. does "echo OK; exit 1", that the user can interpret as correct but that "git rebase" will consider as a failure). It this case, the user would have no simple way to get out of the situation (either --abort or --skip). The current behavior is not that bad: "git rebase --continue" does not re-check the current commit, but the user did have an opportunity to check the commit manually before running it. The problem with rebase (that --exec solves), is that it creates new commits without giving the user this opportunity. I'm not sure adding one more type of command is worth the extra-complexity. > A different proposal would be to add a 'rebase --retry' which would > inoke the last command again. And then the advice after 'exec' could say > "Use --retry to rerun this command, and --continue to proceed with the > next one". > > --retry could make sense for 'apply' commands too: if a commit fails to > apply, one could do [...] That makes sense to me. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- 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