git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Junio C Hamano <gitster@pobox.com>
Date
Sep 7, 2017, 00:55 UTC
Message-ID
<xmqq4lsf2upu.fsf@gitster.mtv.corp.google.com>
In-Reply-To
<CAGZ79kbxDh11KxrKCk_VjmN06kzp7x4iVO6XTV=a-qBmm39K5A@mail.gmail.com>
Stefan Beller <sbeller@google.com> writes:
Show 16 quoted lines
> 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.
Previous: Stefan BellerNext: Shikher Verma
Message 2 of 16 in “Re: [RFC PATCH 0/2] Add named reference to latest push cert”
  1. Stefan BellerSep 6, 2017
  2. Junio C HamanoSep 7, 2017
  3. Shikher VermaSep 7, 2017
  4. Shikher VermaSep 7, 2017
  5. Stefan BellerSep 7, 2017
  6. Shikher VermaSep 16, 2017
  7. Junio C HamanoSep 17, 2017
  8. Santiago TorresSep 18, 2017
  9. Stefan BellerSep 18, 2017
  10. Junio C HamanoSep 19, 2017
  11. Junio C HamanoSep 19, 2017
  12. Add a sample hook which saves push certs as notesShikher Verma, Dec 2, 2017
  13. Todd ZullingerDec 3, 2017
  14. Junio C HamanoDec 3, 2017
  15. Shikher VermaSep 7, 2017
  16. Stefan BellerSep 7, 2017

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.