| Message ID | pull.385.git.gitgitgadget@gmail.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Pass through the exit code of post-checkout | expand |
"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).
This is my attempt to revive an old discussion [https://public-inbox.org/git/20180314003816.GE147135@aiede.svl.corp.google.com/] (related to this StackOverflow thread [https://stackoverflow.com/questions/25561485/git-rebase-i-with-squash-cannot-detach-head] ). > [...] 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. Johannes Schindelin (1): switch/restore: consistently pass through exit code of `post-checkout` Documentation/githooks.txt | 3 ++- builtin/checkout.c | 8 +++++--- t/t5403-post-checkout-hook.sh | 9 +++++++++ 3 files changed, 16 insertions(+), 4 deletions(-) base-commit: 70bf0b755af4d1e66da25b7805cac0e481a082e4 Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-385%2Fdscho%2Fpost-checkout-hook-exit-code-v1 Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-385/dscho/post-checkout-hook-exit-code-v1 Pull-Request: https://github.com/gitgitgadget/git/pull/385