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

> Stefan Beller <sbeller@google.com> writes:
> 
> > On the ref to store the push certs:
> > (a) Currently the ref points at the blob, I wonder if we'd rather want to
> >     point at a commit? (Then we can build up a history of
> >     push certs, instead of relying on the reflog to show all
> >     push certs. Also the gc issue might be easier to solve using this)
> > (b) When going with (a), we might want to change the name. Most
> >     refs are 3 directories deep:
> >       refs/heads/<branch name>
> >       refs/pr/<pull request nr> # at github IIUC
> >       refs/changes/<id> # Gerrit
> >       refs/meta/config # Gerrit to e.g. configure ACLs of the repo
> >     "refs" indicates it is a ref, whereas the second part can be seen
> >     as a "namespace". Currently Git only uses the "heads" and "tags"
> >     namespace, "meta" is used by more than just Gerrit, so maybe it is
> >     not wise to use "refs/meta/push_cert", but go with refs/gitmeta/pushcert
> >     instead?
> 
> You also need to worry about concurrent pushes.  The resulting
> "history" may not have to be sequencial, but two pushes that affect
> the same ref must be serialized in the resulting push-cert store.

> The original design deliberately punts all the complexity to hook
> exactly because we do not want to have a half-baked "built-in"
> implementation that would only get in the way of those who wants to
> do high-performance servers.  It is very likely that they want to
> have a long-running daemon that listens to a port or a named pipe,
> where the only thing the hook would do is to write the value of
> GIT_PUSH_CERT to that daemon process, which acts as a serialization
> point, can read from the object store that is used as a short-term
> temporary area, and write the push cert to a more permanent store.
> 
> Having said all that, I am sympathetic to a wish to have an
> easy-to-enable-without-thinking example that is not so involved
> (e.g. no portability concern, does not have to perform very well but
> must be correct).  If Shikher wants to add one, I think the right
> approach to do so would be to add and ship a sample hook.
>