Subject: Re: [PATCH 7/8] refs: add 'update-symref' command to 'update-ref'

From: Junio C Hamano <[email-masked]>
Date: Mon, 01 Apr 2024 13:40:38 -0700

Junio C Hamano <[email-masked]> writes:

>> But this still means we need to think of the best output for the
>> reference transaction hook (following commit).
>> ...

One thing I missed.  We are not currently reporting symref updates
to these hooks.  Are they prepared to take such extra input?  If not,
are they going to barf when they see "symref-update" while expecting
to see <old-oid>?

We may need to make it possible for Git to tell which variant of the
hook script it was given somehow (the easiest cop-out is to introduce
ref-transaction-hook-v2 as a separate hook, and use it if exists, or
fall back to the reference-transaction hook, and report symref updates
only when we are using v2, but there may be better approaches).

> But this is not an end-user input that tells Git "I do not care
> about precondition, I did not even bother to learn the current state
> to give you as <old-something>, just force it".  The input to hook
> is what we tell the hook what we are planning to do (so that it can
> decline), and we do not need the ability to say "I do not know what
> the current state is".  So I do not think you need any "zero" value
> in the input to the reference-transaction hook.  And I do not see a
> need for the "symref-update-forced" variant, either.

I misspoke here.  We do need "zero" value to indicate that "this
update is a creation event" and "this update is a deletion event".
What I meant to say is that there is no need to make the "zero"
value distinguishable from a "missing optional" value, which was a
problem on the "--stdin" side with "-z" format, where each command
is in a format with fixed number of parameters, unlike the textual
format, where a missing optional argument can be expressed by
omitting SP before the value and the value itself and it can be
differentiated from an empty string as an optional value that is not
missing.

Thanks.