On Thu, Aug 27, 2020 at 8:51 AM Junio C Hamano <gitster@xxxxxxxxx> wrote: > I still suspect that the checkout run, merely as an implementation > detail of rebase (or any other git subcommand), should not trigger > any hook ... The *last* checkout from the finished rebase perhaps *should*, but other than that one, that seems logically correct. > but before any such code change, at least let's update the > documentation to clarify what we mean by "the outcome". > > Hopefully something like the below may be a good starting point? > > Documentation/githooks.txt | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/Documentation/githooks.txt b/Documentation/githooks.txt > index 31b601e4bc..cf95d6d02b 100644 > --- a/Documentation/githooks.txt > +++ b/Documentation/githooks.txt > @@ -193,7 +193,9 @@ worktree. The hook is given three parameters: the ref of the previous HEAD, > the ref of the new HEAD (which may or may not have changed), and a flag > indicating whether the checkout was a branch checkout (changing branches, > flag=1) or a file checkout (retrieving a file from the index, flag=0). > -This hook cannot affect the outcome of `git switch` or `git checkout`. > +This hook cannot affect the outcome of `git switch` or `git checkout`, > +other than that the hook's exit status becomes the exit status of > +these two commands. > > It is also run after linkgit:git-clone[1], unless the `--no-checkout` (`-n`) option is > used. The first parameter given to the hook is the null-ref, the second the This looks good to me, and can either be independent of, or the first part of, any rebase update. Chris
