Junio C Hamano <gitster@xxxxxxxxx> 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.
