Re: [RFC PATCH 0/2] Add named reference to latest push cert

[Stefan Beller <sbeller@google.com>]

On Mon, Sep 18, 2017 at 7:22 AM, Santiago Torres <santiago@nyu.edu> wrote:
> 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.
>>

I put out a vague design that seemed to have more advantages
in my mind at the time of writing. :)

>
> 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.

How would a user benefit from it?
(Are there cases where the organisation wants the user to not know
deliberately what happened to their push cert? Do we care about these
cases?)

>     - *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).

I agree, but many features in Git start out small and only partially.

>     - 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.

That makes sense.