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

From: Matthieu Moy <matthieu.moy@grenoble-inp.fr>
Date: Jun 14, 2012, 06:57 UTC
Message-ID: <vpqr4ticre1.fsf@bauges.imag.fr>
In-Reply-To: <4FD9177A.5030303@in.waw.pl>

Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl> 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.

Show 7 quoted lines

> 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/