On Wed, Sep 6, 2017 at 2:39 AM, Shikher Verma <r...@shikherverma.com> wrote:
> Currently, git only stores push certificates if there is a receive hook
> present. This may violate the principle of least surprise (e.g., I
> pushed with --signed, and I don't see anything in upstream).
> Additionally, push certificates could be more versatile if they are not
> tightly bound to git hooks. Finally, it would be useful to verify the
> signed pushes at later points of time with ease.
>
> A named ref is added for ease of access/tooling around push
> certificates. If the last push was signed, ref/PUSH_CERT stores the
> ref of the latest push cert otherwise it is empty.
>
> Sending patches as RFC since the documentation would have to be
> updated and git gc might have to be patched to not garbage collect
> the latest push certificate.
>
> This patch applies on master (3ec7d702a)
What are performance implications for busy repositories at busy hosts?
(think kernel.org / github) They may want to disable this new feature
for performance reasons or because they don't want to clutter the
object store. So at least a config option to turn it off would be useful.
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?
