Re: [PATCH 0/1] Pass through the exit code of post-checkout

[Junio C Hamano <gitster@pobox.com>]

"Johannes Schindelin via GitGitGadget" <gitgitgadget@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).