How to run tests for all commits during a rebase

While you are on branch feature execute:

git rebase --interactive --exec "ant rebuild test" C

This will cause git to start again on commit C, replay your work on top and it will run your tests after each commit it applies during replay phase.

Hopefully your ant task will have a non-zero exit code if your tests fail. In this case git will stop as soon as the tests fail. You are immediately in the right position to amend you commit so that the tests will be happy again. After you have amended just execute git rebase --continue as usual and git will continue to check all you commits.

To add to the OP yankee's excellent answer, Git 2.5+ will provide a more robust git rebase --interactive --exec experience, especially in case of a failed exec.
Actually, see the new --reschedule-failed-exec of Git 2.21 in the last part of this answer.

See commit b12d3e9 [22 May 2015], and commit 1d968ca [22 May 2015] by Matthieu Moy (moy).
^{(Merged by Junio C Hamano -- gitster -- in commit a6be52e, 01 Jun 2015)}

The 'exec' command is sending the current commit to stopped-sha, which is supposed to contain the original commit (before rebase).
As a result, if an 'exec' command fails, the next 'git rebase --continue' will send the current commit as to the post-rewrite hook.

---

The full documentation:

rebase -i: fix post-rewrite hook with failed exec command

Usually, when 'git rebase' stops before completing the rebase, it is to give the user an opportunity to edit a commit (e.g. with the 'edit' command).
In such cases, 'git rebase' leaves the sha1 of the commit being rewritten in "$state_dir"/stopped-sha, and subsequent 'git rebase --continue' will call the post-rewrite hook with this sha1 as <old-sha1> argument to the post-rewrite hook.

The case of 'git rebase' stopping because of a failed 'exec' command is different: it gives the opportunity to the user to examine or fix the failure, but does not stop saying "here's a commit to edit, use --continue when you're done".
So, there's no reason to call the post-rewrite hook for 'exec' commands.
If the user did rewrite the commit, it would be with 'git commit --amend' which already called the post-rewrite hook.

Fix the behavior to:

• leave no stopped-sha file in case of failed exec command,

• and teach 'git rebase --continue' to skip record_in_rewritten if no stopped-sha file is found.

---

To facilitate managing failed exec directives associated to a rebase, Git 2.21 (Q1 2019) introduces --reschedule-failed-exec, with "git rebase -i", which learned to re-execute a command given with 'exec' to run after it failed the last time.

See commit 81ef8ee, commit 969de3f, commit d421afa (10 Dec 2018) by Johannes Schindelin (dscho).
^{(Merged by Junio C Hamano -- gitster -- in commit d9d9ab0, 29 Jan 2019)}

rebase: introduce --reschedule-failed-exec

A common use case for the --exec option is to verify that each commit in a topic branch compiles cleanly, via git rebase -x make <base>.

However, when an exec in such a rebase fails, it is not re-scheduled, which in this instance is not particularly helpful.

Let's offer a flag to reschedule failed exec commands.

Based on an idea by Paul Morelle.

The git rebase man page now includes:

--reschedule-failed-exec::

--no-reschedule-failed-exec::

Automatically reschedule exec commands that failed.
This only makes sense in interactive mode (or when an --exec option was provided).

And:

rebase: introduce a shortcut for --reschedule-failed-exec

It is a bit cumbersome to write out the --reschedule-failed-exec option before -x <cmd> all the time; let's introduce a convenient option to do both at the same time: -y <cmd>.

Note: the first committed in reverted in See commit e11ff89 (06 Feb 2019), and commit 81ef8ee (10 Dec 2018) by Johannes Schindelin (dscho).
^{(Merged by Junio C Hamano -- gitster -- in commit b966813, 09 Feb 2019)}

Revert "rebase: introduce a shortcut for --reschedule-failed-exec"

This patch was contributed only as a tentative "we could introduce a convenient short option if we do not want to change the default behavior in the long run" patch, opening the discussion whether other people agree with deprecating the current behavior in favor of the rescheduling behavior.

But the consensus on the Git mailing list was that it would make sense to show a warning in the near future, and flip the default rebase.rescheduleFailedExec to reschedule failed exec commands by default.

So let's back out that patch that added the -y short option that we agreed was not necessary or desirable.

---

Also in Git 2.21 (Feb. 2019): "git rebase -x $cmd" did not reject multi-line command, even though the command is incapable of handling such a command.
It now is rejected upfront.

See commit c762aad (29 Jan 2019) by Phillip Wood (phillipwood).
^{(Merged by Junio C Hamano -- gitster -- in commit 96e6547, 07 Feb 2019)}

rebase -x: sanity check command

If the user gives an empty argument to --exec then git creates a todo list that it cannot parse. The rebase starts to run before erroring out with:

error: missing arguments for exec

error: invalid line 2: exec
You can fix this with 'git rebase --edit-todo' and then run 'git rebase --continue'.
Or you can abort the rebase with 'git rebase --abort'.

Instead check for empty commands before starting the rebase.

Also check that the command does not contain any newlines as the todo-list format is unable to cope with multiline commands.
Note that this changes the behavior, before this change one could do:

git rebase --exec='echo one

exec echo two'

and it would insert two exec lines in the todo list, now it will error out.

---

With Git 2.23, the configuration variable rebase.rescheduleFailedExec should be effective only while running an interactive rebase and should not affect anything when running an non-interactive one, which was not the case.
This has been corrected.

See commit 906b639 (01 Jul 2019) by Johannes Schindelin (dscho).
^{(Merged by Junio C Hamano -- gitster -- in commit 64096fb, 11 Jul 2019)}

rebase --am: ignore rebase.rescheduleFailedExec

The exec command is specific to the interactive backend, therefore it does not make sense for non-interactive rebases to heed that config setting.

We still want to error out if a non-interactive rebase is started with --reschedule-failed-exec, of course.

Reported by Vas Sudanagunta via commit 969de3f.

---

"git rebase --[no-]reschedule-failed-exec"^(man) did not work well with its configuration variable, which has been corrected with Git 2.32 (Q2 2021).

See commit e5b32bf, commit cd663df (09 Apr 2021) by Ævar Arnfjörð Bjarmason (avar).
^{(Merged by Junio C Hamano -- gitster -- in commit 0377ac9, 07 May 2021)}

rebase: don't override --no-reschedule-failed-exec with config

^{Signed-off-by: Ævar Arnfjörð Bjarmason}

Fix a bug in how --no-reschedule-failed-exec interacts with rebase.rescheduleFailedExec=true being set in the config.
Before this change the --no-reschedule-failed-exec config option would be overridden by the config.

This bug happened because of the particulars of how "rebase" works v.s.
most other git commands when it comes to parsing options and config:

When we read the config and parse the CLI options we correctly prefer the --no-reschedule-failed-exec option over rebase.rescheduleFailedExec=true in the config.
So far so good.

However the --reschedule-failed-exec option doesn't take effect when the rebase starts (we'd just create a ".git/rebase-merge/reschedule-failed-exec" file if it was true).
It only takes effect when the exec command fails, at which point we'll reschedule the failed "exec" command.

Since we only wrote out the positive ".git/rebase-merge/reschedule-failed-exec" under --reschedule-failed-exec, but nothing with --no-reschedule-failed-exec we'll forget that we asked not to reschedule failed "exec", and would happily re-read the config and see that rebase.rescheduleFailedExec=true is set.

So the config will effectively override the user having explicitly disabled the option on the command-line.

Even more confusingly: Since rebase accepts different options based on its state there wasn't even a way to get around this with "rebase --continue --no-reschedule-failed-exec^(man) (but you could of course set the config with "rebase -c ...").

I think the least bad way out of this is to declare that for such options and config whatever we decide at the beginning of the rebase goes.
So we'll now always create either a "reschedule-failed-exec" or a "no-reschedule-failed-exec file at the start, not just the former if we decided we wanted the feature.

With this new worldview you can no longer change the setting once a rebase has started except by manually removing the state files discussed above.
I think making it work like that is the the least confusing thing we can do.

In the future we might want to learn to change the setting in the middle by combining "--edit-todo" with "--[no-]reschedule-failed-exec", we currently don't support combining those options, or any other way to change the state in the middle of the rebase short of manually editing the files in ".git/rebase-merge/*".

The bug being fixed here originally came about because of a combination of the behavior of the code added in d421afa ("rebase: introduce --reschedule-failed-exec", 2018-12-10, Git v2.21.0-rc0 -- merge listed in batch #4) and the addition of the config variable in 969de3f ("rebase: add a config option to default to --reschedule-failed-exec", 2018-12-10, Git v2.21.0-rc0 -- merge listed in batch #4).

git rebase now includes in its man page:

Even though this option applies once a rebase is started, it's set for the whole rebase at the start based on either the rebase.rescheduleFailedExec configuration (see git config or "CONFIGURATION" below) or whether this option is provided.
Otherwise an explicit --no-reschedule-failed-exec at the start would be overridden by the presence of rebase.rescheduleFailedExec=true configuration.