For a project I have a pre-commit hook that monitors whether files in a folder (scripts of DB) changed or not and fails if another special file (DB version) did not changed, too. So, I did some commits and then I decided to change the order of them. Of course, I used a lovely "git rebase -i" command. I changed the order of the commits, then rebasing went ok. But I noticed that my pre-commit hook output failure message (one of the commits did not meet above-mentioned condition). It's not too bad but ugly. But when I decided to correct a message of that specific commit I ran "git rebase -i" again, marked that commit for rewording, rewording did not start (because pre-commit hook failed, obviously) and rebasing went on (commit had an unchanged message) and successfully finished. That is not what I expected. I guess if any of hooks fail (which usually fail the commit), rebasing have to be interrupted (as when there are conflicts) Here is a sample to reproduce the error git init . echo content > file git add -fv file git commit -a -m 'first commit' echo line 2 >> file git commit -a -m 'secont commit' # note a typo ;) echo '#!/bin/bash echo commit failed exit 1' > .git/hooks/pre-commit chmod +x .git/hooks/pre-commit echo fail >> file git commit -a -m 'failed commit' # to show that pre-commit hook fails # and outputs "commit failed" git reset --hard git rebase -i HEAD^ # mark commit for rewording and exit an editor note following output after all this: >commit fail/1) >Successfully rebased and updated refs/heads/master -- 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