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