Hello, everyone.

Sorry for being late in this thread, I was making sure I didn't say
anything outrageously wrong. 

> That's Stefan; I wouldn't have suggested any approach that uses the
> blob whose sole purpose is to serve as a temporary storage area to
> pass the information to the hook as part of the permanent record.
> 

Hmm, as far as I understand *this* is the status quo. We get an
ephemeral sha1/oid only if you have a hook attached. Otherwise, you will
never see the object at all, even if you have --signed set.

I suggested preparing this RFC/Patch because of the following reasons
(please let me know if my understanding of any of this is wrong...):

    - I find it weird that the cli allows for a --signed push and
      nowhere in the receive-pack's feedback you're told if the push
      certificate is compute/stored/handled at all. I think that, at the
      latest, receive pack should let the user know whether the signed
      push succeeded, or if there is no hook attached to handle it.

    - *if there is a hook* the blob is computed, but it is up to the
      hook itself to store it *somewhere*. This makes me feel like it's
      somewhat of a useless waste of computation if the hook is not
      meant to handle it anyway(which is just a post-receive hook). I
      find it rather weird that --signed is a builtin flag, and is
      handled on the server side only partially (just my two cents).

    - To me, the way push certificates are handled now feels like having
      git commit -S producing a detached signature that you have to
      embed somehow in the resulting commit object. (As a matter of
      fact, many points on [1] seem to back this notion, and even recall
      some drawbacks on push certificates the way they are handled
      today)

I understand the concurrency concerns, so I agree with stefan's
solution, although I don't know how big of a deal it would be, if git
already supports --atomic pushes (admittedly, I haven't checked if there
are any guards in place for someone who pushes millions of refs
atomically). It'd be completely understandable to have a setting to
disable hadnling of --signed pushes and, ideally, a way to warn the user
of this feature being disabled if --signed is sent.

Maybe I'm missing the bigger picture, but to me it feels that a named
ref to the latest push certificate would make it easier to
handle/tool/sync around the push certificate solution?

Thanks,
-Santiago.

[1] https://public-inbox.org/git/CAJo=hJvWbjEM9E5AjPHgmQ=eY8xf=Q=xtukeu2Ur7auUqeabDg@mail.gmail.com/