Re: [RFC PATCH 0/2] Add named reference to latest push cert
- Date: Thu, 7 Sep 2017 14:25:11 +0530
- From: Shikher Verma <root@xxxxxxxxxxxxxxxx>
- Subject: Re: [RFC PATCH 0/2] Add named reference to latest push cert
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?