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

Re: [RFC/PATCH v1] Add Travis CI support

From
Shawn Pearce <spearce@spearce.org>
Date
Sep 26, 2015, 21:54 UTC
Message-ID
<CAJo=hJuj04nZS3qPe+QcvihoMVJ1JUL7eG5gdVU-V_FPdLn1tQ@mail.gmail.com>
In-Reply-To
<20150925185227.GA15190@sigill.intra.peff.net>
On Fri, Sep 25, 2015 at 11:52 AM, Jeff King <peff@peff.net> wrote:
Show 16 quoted lines
> On Fri, Sep 25, 2015 at 11:29:31AM -0700, Junio C Hamano wrote:
>
>> >  So I wonder if it would be
>> > helpful to have a microformat that the client would use to look at this.
>> > E.g., it would fetch the cert tree, then confirm that the current ref
>> > values match the latest cert.
>>
>> Yeah, that is one possibility.  Just a single flat file that
>> concatenates all the push cert in the received order would do as an
>> export format, too ;-)
>
> I agree that's a more logical format, in a sense; it really is a linear
> log. It's just that the receive-pack code already creates a blob for us,
> so it's cheap to reference that in tree (and then fetching it is cheap,
> too). IOW, git is much better at adding files to trees than it is at
> appending to files. :)

FWIW JGit has a micro-format[1] we are starting to use. Its a tree of the push cert blobs anchored under refs/meta/push-certs.

Inspired by a proposal from gitolite[2], where we store a file in a tree for each ref name, and the contents of the file is the latest push cert to affect that ref.

The main modification from that proposal (other than lacking the out-of-git batching) is to append "@{cert}" to filenames, which allows storing certificates for both refs/foo and refs/foo/bar. Those refnames cannot coexist at the same time in a repository, but we do not want to discard the push certificate responsible for deleting the ref, which we would have to do if refs/foo in the push cert tree changed from a tree to a blob.

[1] https://eclipse.googlesource.com/jgit/jgit/+/d5a71e9ca3d95330acdd858306c4f75ae0b01e58 [2] https://github.com/sitaramc/gitolite/blob/cf062b8bb6b21a52f7c5002d33fbc950762c1aa7/contrib/hooks/repo-specific/save-push-signatures

Previous: Jeff King
Message 31 of 31 in “Add Travis CI support”
  1. Add Travis CI supportlarsxschneider@gmail.com, Sep 24, 2015
  2. Add Travis CI supportlarsxschneider@gmail.com, Sep 24, 2015
  3. Junio C HamanoSep 25, 2015
  4. Dennis KaarsemakerSep 25, 2015
  5. Johannes SchindelinSep 25, 2015
  6. Luke DiamandSep 25, 2015
  7. Junio C HamanoSep 25, 2015
  8. Lars SchneiderSep 26, 2015
  9. Matthieu MoySep 27, 2015
  10. Stefan BellerSep 28, 2015
  11. Matthieu MoySep 28, 2015
  12. Junio C HamanoSep 28, 2015
  13. Matthieu MoySep 28, 2015
  14. Roberto TyleyOct 3, 2015
  15. Junio C HamanoOct 4, 2015
  16. Junio C HamanoOct 4, 2015
  17. Dennis KaarsemakerOct 4, 2015
  18. Johannes SchindelinOct 4, 2015
  19. Matthieu MoyOct 4, 2015
  20. Junio C HamanoOct 4, 2015
  21. Dennis KaarsemakerOct 4, 2015
  22. Matthieu MoyOct 5, 2015
  23. Junio C HamanoOct 5, 2015
  24. Sebastian SchuberthOct 12, 2015
  25. Junio C HamanoOct 4, 2015
  26. Jeff KingOct 4, 2015
  27. Sebastian SchuberthOct 2, 2015
  28. Jeff KingSep 25, 2015
  29. Junio C HamanoSep 25, 2015
  30. Jeff KingSep 25, 2015
  31. Shawn PearceSep 26, 2015

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.