On Thu, Sep 07, 2017 at 09:55:25AM +0900, Junio C Hamano wrote: > Stefan Beller <sbeller@xxxxxxxxxx> 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. Oh I see. I guess concurrency would be an issue. How does recieve-pack handle concurrent pushes? Is there a lock that I could use to decide if named push cert ref has to be updated or not? > 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. > This patch would only add one more object to write per push so I think the performance penalty is not that high. We can have a config to turn it off so that it does not get in the way of those who want to do high-performance servers. People can use the recieve hook for advance use cases but I think git should provide a builtin solution for the simple case. The reason I favour a named ref over a sample hook is because decouping push certificate from hook opens up more possibilities like we could store a map of refs to the latest push cert which updated the ref. And serve the corresponding push cert whenever someone does `git pull --signed important-ref`. Effectively removing trust from the server by preventing tampering with refs. This could really help the Github generation developers like me. What do you think? > Thanks.
