On 06/14/2012 12:35 AM, Junio C Hamano wrote: > 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". 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 git reset --hard HEAD^ hack hack adjusting the preimage git commit git rebase --retry Using --retry to rerun tests would have the advantage that one normally doesn't think that the tests will fail, so could get into the habit of using 'exec', not 'test', for the verification commands. Just thinking aloud. Zbyszek -- 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