Andreas Politz <poli...@hochschule-trier.de> writes: > the exit value of a `git checkout' seems to depend on the exit values of > the hooks it runs. This breaks for example `git bisect', as seen in the > following example.
I am a bit puzzled why you have "checkout" and "post-commit" on the title, though. Does checkout call a hook for "commit"? Any script that calls "git checkout" and sees it fail should not blindly continue its usual processing; if "git bisect" notices an error from "git checkout" it internally runs and stops, it is doing the right thing. A hook script that tries to do something during the main command (e.g. "git checkout") and fails to do what it wanted to do needs a way to tell the main command that it failed, and the way for it to do so is to exit with non-zero status. Upon seeing such an error, the main command needs to relay the error to the end user, as the operation as the whole (i.e. what the main command does, in addition to what the end user wanted to customize by running the hook) failed. So if your hook tells "git checkout" it failed to do something it wanted to do, it is very sensible for that error to percolate up. If that is not wanted, perhaps you should stop exiting with a failure status from your hook when it did not fail?
