On Tue, Jan 19, 2021 at 11:06:15PM -0800, Junio C Hamano wrote:
> Patrick Steinhardt <ps@xxxxxx> writes:
>
> >> Even without this change, the current value the hook can learn by
> >> looking the ref up itself if it really wanted to, no?
> >
> > I think the biggest problem is that right now, you cannot discern the
> > actual intention of the user because the information provided to the
> > hook is ambiguous in the branch creation case: "$ZERO_OID $NEW_OID $REF"
> > could mean the user intends to create a new branch where it shouldn't
> > have existed previously. BUT it could also mean that the user just
> > doesn't care what the reference previously pointed to.
>
> Yes, it can mean both, but when you pretend to be that hook,
> wouldn't you check if the ref exists? If not, the user is trying to
> create it, and otherwise, the user does not know or care what the
> original value is, no?
As long as you're aware as the script author, yes.
There is one gotcha though: you can verify the state when the
reference-transaction hook gets invoked in the "prepared" state, as it
means that all references have been locked and thus cannot be changed by
any other well-behaved process accessing the git repository. In
"committed" or "aborted" that's not true anymore, given that the state
has changed already, so any locks have been released and it's impossible
to find out what happened now.
> > The user could now try to derive the intention by manually looking up
> > the current state of the reference. But that does feel kind of awkward
> > to me.
>
> So in short, with respect to the OLD slot, there are three kind of
> end-user intention that could be conveyed to the hook:
>
> (1) the user does not care, so 0{40} appears in the OLD slot here,
> (2) the user is creating, so 0{40} apears in the OLD slot here, and
> (3) the user does care, and this is the OID in the OLD slot,
>
> And (1) and (2) cannot be separated without looking at the ref (in
> other words, if the hook really cares, it can find it out).
>
> But if you replace 0{40} with the current OID, then you are making
> it impossible to tell (1) and (3) apart. The hook cannot tell the
> distinction even if it is willing to go the extra mile.
>
> So that sounds like a strict disimprovement to me.
True.
> If you can invent a way to help the hook to tell all three apart, I
> am very much interested. It would earn you a bonus point if you can
> do so without breaking backward compatibility (but I doubt that it
> is possible).
I did think about any way to do this, but wasn't yet able to find one.
And doing it in a backwards-compatible way is probably going to be
impossible. One idea I had is to use something similar to the
peeled-format we use in packed refs in case the actual change is
different from the user-provided change. E.g.
0{40} <new> <ref>
^<old>
or
0{40}^<old> <new> <ref>
That can be considered as backwards-incompatible though.
> > To me, having clearly defined semantics ("The script always gets old and
> > new value of the branch regardless of what the user did") is preferable
> > to having ambiguous semantics.
>
> But "The script always gets old that was given by the user and the
> new value to be stored" is very clearly defined semantics already.
>
> On the other hand, "The script gets a non-NULL object name in both
> cases, either when the user says s/he does not care, or when the
> user insists that the old value must be that, and it is not just
> ambiguous but is impossible to tell apart" is worse than just being
> ambiguous.
Yup. Whatever we agree on, what is clear is that the documentation needs
to be more specific here.
Patrick
Attachment:
signature.asc
Description: PGP signature
