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

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 11, 2019, 04:22 UTC
Message-ID: <xmqqo8ynj4hd.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <pull.385.git.gitgitgadget@gmail.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).