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

Re: [PATCH 2/2] push -s: skeleton

From
Jeff King <peff@peff.net>
Date
Sep 9, 2011, 15:22 UTC
Message-ID
<20110909152248.GA28480@sigill.intra.peff.net>
In-Reply-To
<CAJo=hJsQvRN3Z0xJg9q37Km1g_1qUdJKNQ6n8=a9mv3YjugyVw@mail.gmail.com>
On Thu, Sep 08, 2011 at 03:07:25PM -0700, Shawn O. Pearce wrote:
> A notes tree per ref is ugly when you have a lot of branches. Its a
> problem when you merge commits from say "maint" over to "master" 2
> days after they were initially pushed. Ideally the notes tree for
> master also includes what you brought over.

I agree you can end up with a lot of refs if you have a lot of branches, and that may get a bit unwieldy. I don't see how the merge thing is a problem, though. If you do the merge at a client, then those commits will hit master by push, and you'll get entries in the cert tree for master. If you do the merge locally, then there's not going to be a signature on those commits hitting the master ref, no matter what the storage scheme.

Show 18 quoted lines
> However, maybe it is reasonable for a protocol extension to support
> "auto-notes-merge" on a refs/notes/ ref if the client asks for it in
> the send-pack/receive-pack command stream? Clients could push notes
> and have the server automatically merge the client's pushed commit
> into the notes tree, either by fast-forward or by performing an
> automatic notes merge, with concat being applied to non-identical
> notes on the same SHA-1. This would allow the client to prepare his
> local certificate, and push that notes tree, while still working
> around the race on the server side.
> 
> If the server doesn't support the protocol extension, the client can
> still push his signed notes, he just may run into a race with another
> concurrent user pushing into the same repository. Which then means
> that an upgrade of the server is really only important/necessary if
> you have "central repository" model that a lot of users push into. If
> you use the traditional workflow that GitHub encourages of per-user
> repositories, you would never have a race on the server, and wouldn't
> need the upgraded server binary with "auto-notes-merge".

I like this approach, as the protocol extension provides the minimal building block that can be used to implement this, or any other notes-related scheme.

-Peff
Previous: Junio C Hamano
Message 26 of 26 in “send-pack: typofix error message”
  1. 1/2 send-pack: typofix error messageJunio C Hamano, Sep 7, 2011
  2. 2/2 push -s: skeletonJunio C Hamano, Sep 7, 2011
  3. Shawn PearceSep 7, 2011
  4. Junio C HamanoSep 7, 2011
  5. Shawn PearceSep 7, 2011
  6. Junio C HamanoSep 8, 2011
  7. Nguyen Thai Ngoc DuySep 7, 2011
  8. Junio C HamanoSep 7, 2011
  9. Robin H. JohnsonSep 7, 2011
  10. Jeff KingSep 8, 2011
  11. Robin H. JohnsonSep 9, 2011
  12. Joey HessSep 9, 2011
  13. Drew NorthupSep 9, 2011
  14. Jeff KingSep 9, 2011
  15. 3/2 Split GPG interface into its own helper libraryJunio C Hamano, Sep 8, 2011
  16. 4/2 push -s: send signed push certificateJunio C Hamano, Sep 8, 2011
  17. 5/2 push -s: receiving endJunio C Hamano, Sep 8, 2011
  18. Johan HerlandSep 8, 2011
  19. Junio C HamanoSep 8, 2011
  20. Jeff KingSep 8, 2011
  21. Junio C HamanoSep 8, 2011
  22. Jeff KingSep 8, 2011
  23. Junio C HamanoSep 8, 2011
  24. Jeff KingSep 9, 2011
  25. Junio C HamanoSep 9, 2011
  26. Jeff KingSep 9, 2011

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.