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

[Junio C Hamano <gitster@pobox.com>]

Johannes Sixt <j6t@kdbg.org> writes:

> Not so fast.
>
> 	exec cmd1 && cmd2
> and
> 	exec cmd1
> 	exec cmd2
>
> are far from equivalent: If cmd1 fails, the first version never runs
> cmd2, but the second version runs cmd2 upon rebase --continue.

This reminds me of one thing.

For "exec" insns that are meant to validate each commit in the
resulting history, what should happen (I am not asking what the
current implementation of "rebase -i" does) after "exec cmd1" fails?

Ideally, the user will at that point fix the problem in the code,
run "commit --amend" to record the fix, and then want to make sure
it really fixed it by re-running "exec cmd1", no?

Shouldn't "rebase --continue" after such a "commit --amend" resume
execution from "exec cmd1", which failed in the initial run?

I said in the beginning 'For "exec" insns that are meant to validate',
as "exec" is not necessarily about validation, and other use cases
of it may want it run only once in the sequence, whether it succeeds
or fails.  So perhaps we would need two kinds of "exec", one that
just runs once and is not re-run even if the initial round fails,
and another (perhaps spell it "test") that runs upon "--continue"
until it passes.  The latter of course can be skipped by the user
with "rebase --skip".