"Johannes Schindelin via GitGitGadget" <gitgitgad...@gmail.com> writes:
> To answer Jonathan's question, at long last, yes, it is useful. A hook is > not only an opportunity to run code at given points in Git's life cycle, but > also an opportunity to stop Git in its tracks. In general that is correct, and especially so for pre_$git_action hooks, which are about interfering and vetoing an action that is being carried out. On the other hand, post_$git_action hooks are specifically defined as a way to trigger an extra action and documented that they cannot affect the outcome of the operation (in other words, they trigger at a point in the operation flow that is too late to affect the outcome). Now, it is somewhat debatable how the "outcome" should be defined. A post-rebase hook that drops the last commit in the sequence, for example, should not be allowed (the rebase has rebuilt a sequence and that final sequence of commits should be left), but should it be allowed to signal back to "git rebase" and affect its exit status? I am not 100% sure if it is a good idea to allow post-checkout to affect the exit status of "git checkout" or its friends. If one codepath in "git checkout" or its friends lets post-checkout to influence the exit status while another codepath ignores, it makes sense to discuss if the inconsistency needs to be removed, but in such a case, I think it would make sense to unify in the direction of ignoring (i.e. not allowing post-* hook to affect the outcome).
