Re: post-checkout hook aborts rebase

>
> Hi Tom
>
> On 27/08/2020 01:44, Tom Rutherford wrote:
> > Thank you for the response Junio.
> >
> > For what it's worth, my hook does not make changes to the repo. It's
> > running a command to check that the installed version of our
> > dependencies match the version specified in the commit being checked
> > out, and merely warns if the two don't match (then exits with a
> > nonzero return code).
> >
> > For this reason it's been convenient that the hook runs during
> > rebases, but I find it surprising that the nonzero return code would
> > impact the rebase.
>
> If the checkout succeeds that rebase does not print any of checkout's
> output so unfortunately you wouldn't see the message from your hook.
>
> I tend to agree with Junio that we shouldn't be running the
> post-checkout hook when rebasing.
>
> Best Wishes
>
> Phillip
>
> >
> > Tom
> >
> > On Wed, Aug 26, 2020 at 5:22 PM Junio C Hamano <gitster@pobox.com> wrote:
> >>
> >> Junio C Hamano <gitster@pobox.com> writes:
> >>
> >>> ...  If "git rebase" or whatever
> >>> command wanted to place files and the index into some state by using
> >>> "git checkout" command, and if the post-checkout hook mucked with
> >>> the state in such a way that contradicts with what the "git rebase"
> >>> command wanted them to be in, it is not surprising the hook's behavior
> >>> broke "git rebase"'s operation.
> >>
> >> Having said all that, I actually think that "rebase" shouldn't be
> >> invoking "git checkout" (and its equivalent) internally when
> >> switching to a specific version, in such a way that it would trigger
> >> any end-user specified hooks and allow them to muck with the working
> >> tree and the index state.
> >>
> >> I haven't checked the actual implementation of "git rebase" for
> >> quite some time to be sure, but we have lower-level plumbing
> >> commands that are not affected by the end-user hooks for exactly
> >> that kind of "build higher-level commands by synthesis of
> >> lower-level machinery", and it is very possible that what we are
> >> looking at is actually a bug that needs to be fixed.  I dunno.
> >>
> >> Thanks.
>