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

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 19, 2017, 01:04 UTC
Message-ID: <xmqqk20vsdmm.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <20170918142205.r5kwkq7ouy5zxisz@LykOS.localdomain>

Santiago Torres <santiago@nyu.edu> writes:

Show 6 quoted lines

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

The way it was envisioned to be used is that the repository meant to be protected by collected push certs may not be trusted as the permanent store for push certs by all hosting sites. The hook may be told the name of a blob to read its contents and is expected to store it away to somewhere else.

The only reason why we use blob is because creating a blob in respose to pushes being executed in parallel will result in different blobs unless there is hash collision. Instead of us having to come up with and use a different mechanism to create a unique temporary filename and feed that to hook, reusing blob as such was the simplest.

Show 7 quoted lines

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

I do not think atomic helps at all, when one atomic push updates branch A while another atomic push updates branch B. They can still go in parallel, and their certificates must both be stored. You can somehow serialize them and create a single strand of pearls to advance a single ref, or you can let both to fork two histories to store the push certs from these two pushes and have somebody create a merge commit to join the history.

But the point is that we do not want such an overhead in core, as all of that is a useless waste of the cycle for a site that wants to store the push certificate away outside of the repository itself.