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

From: Stefan Beller <sbeller@google.com>
Date: Sep 6, 2017, 21:31 UTC
Message-ID: <CAGZ79kbxDh11KxrKCk_VjmN06kzp7x4iVO6XTV=a-qBmm39K5A@mail.gmail.com>
In-Reply-To: <20170906093913.21485-1-root@shikherverma.com>

On Wed, Sep 6, 2017 at 2:39 AM, Shikher Verma <root@shikherverma.com> wrote:

Show 16 quoted lines

> 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?