Johannes Sixt <j6t@xxxxxxxx> 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". -- 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