Stefan Beller <sbel...@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. Thanks.
