From: Matthieu Moy <matthieu.moy@grenoble-inp.fr>
Date: Thu, 14 Jun 2012 06:57:26 GMT
Subject: Re: [PATCHv5] rebase [-i --exec | -ix] <CMD>...
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.

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