Patrick Steinhardt [off-list ref] writes:
quoted
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?
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.
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).
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.
On Tue, Jan 19, 2021 at 11:06:15PM -0800, Junio C Hamano wrote:
Patrick Steinhardt [off-list ref] writes:
quoted
quoted
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.
quoted
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.
quoted
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