Pass through the exit code of post-checkout

[dscho]

This is my attempt to revive an old discussion (related to this StackOverflow thread).

[...] is this the right behavior for "git checkout" to have? I.e. is it useful for "git checkout" to fail when the post-checkout hook fails, or would it be better for it to e.g. simply print a message and exit with status 0?

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. Further, if you script the operation, it may very well be useful to discern between an exit code from Git's operation from an exit code produced by your hook.

If you don't want your git checkout/git switch/git restore to fail due to a post-checkout failure, just make sure that that hook does not fail ;-) (This could easily be achieved by trap EXIT { exit 0; }, I believe.

I discovered, however, that the original patch contribution missed that a git checkout -b <branch> will not pass through the exit code, but instead return exit code 1. As part of my contribution, I fix this, and also introduce a regression test to document the now-consistent behavior.

Cc: Jonathan Nieder [email protected], Magne Land [email protected]

[dscho]

/submit

[gitgitgadget]

Submitted as [email protected]

[gitgitgadget]

On the Git mailing list, Junio C Hamano wrote (reply to this):

"Johannes Schindelin via GitGitGadget" <[email protected]>
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).