Re: [PATCHv5] rebase [-i --exec | -ix] <CMD>...

Zbigniew Jędrzejewski-Szmek [off-list ref] writes:

quoted

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/

On 12-06-14 02:57 AM, Matthieu Moy wrote:

Zbigniew Jędrzejewski-Szmek [off-list ref] writes:

quoted

quoted

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.