Re: post-checkout hook aborts rebase

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Thanks Phillip,

Yes, I've now noticed that's the case. :)

I also didn't intend to suggest that post-checkout *should* run during
rebases, just that it would be convenient for this particular use case
if it did.
I think I'll need to use multiple hooks to accomplish what I want to do.


Tom

On Wed, Sep 9, 2020 at 2:44 AM Phillip Wood <phillip.wood123@xxxxxxxxx> wrote:
>
> 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@xxxxxxxxx> wrote:
> >>
> >> Junio C Hamano <gitster@xxxxxxxxx> 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.
>



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux