On Thu, Feb 25, 2021 at 08:01:11AM +0200, Yaron Wittenstein wrote:
> Thank you for the clarification!
> 
> Is there any plan to support such a case in the future?

I personally don't have any plans to do so, but I can see usecases where
it would make sense. So I wouldn't be opposing any such efforts either.

> Also, I've observed that the "post-index-change" hook is being
> triggered before calling the "reference-transaction" hook (with the
> "prepared" state). It seems not intuitive to me since the index and
> working dirs are being updated before approving the transaction. (the
> HEAD still points to an "old" reference while the "post-index-change"
> hook is executing).

This is something that cannot really be helped though. The
reference-transaction hook directly hooks into the reference transaction
mechanism, which is how git updates all references. So we do not really
have any control over when the hook will get executed: it will simply
get executed whenever the reference transaction itself gets prepared
(refs get locked) and committed (written updated refs got moved into
place).

And that's by design: my objective was to catch _all_ reference updates
such that one can coordinate across multiple git nodes which all perform
the same action to assert they're moving from the same state to the same
state, regardless of whether they're doing a git-push(1), git-merge(1)
or git-update-ref(1).

So what you're observing is simply mirroring "reality": the order in
which git does its things here. There can be arbitrarily many
transactions in a given git command, and the only way this can be
changed is by changing how the command operating the transcations works.

Patrick

> Thank you,
>    Yaron
> 
> On Thu, Feb 25, 2021 at 7:37 AM Patrick Steinhardt <ps@pks.im> wrote:
> >
> > On Wed, Feb 24, 2021 at 04:03:14PM -0500, Jeff King wrote:
> > > On Wed, Feb 24, 2021 at 10:21:55PM +0200, Yaron Wittenstein wrote:
> > >
> > > > That indeed seems to do the trick.
> > > > I've done a little experiment and saw that when doing git reset the
> > > > hook gets called.
> > > >
> > > > However, when switching branches the hook doesn't execute :(
> > > >
> > > > I don't understand if it's intentional, since when I've moved to a new
> > > > branch HEAD pointed to another commit id.
> > > > The only workaround I see here is using the post-checkout hook in addition.
> > >
> > > Hmm, I would have thought that the branch switch would trigger the hooks
> > > because they're updating HEAD. I wonder if that is a bug (or lack of
> > > feature :) ) in the transaction hooks, or something Patrick did
> > > intentionally.
> > >
> > > -Peff
> >
> > It was done semi-intentionally, or at least with the knowledge that
> > symrefs aren't covered. This is mostly because they're not covered by
> > the reference transaction mechanism itself.
> >
> > But this again reminds me that I still have to update the documentation
> > of the hook to at least make it more explicit what's currently covered
> > and what's not.
> >
> > Patrick