All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Shawn Pearce <spearce@spearce.org>
Cc: Junio C Hamano <gitster@pobox.com>, git@vger.kernel.org
Subject: Re: [PATCH 2/2] push -s: skeleton
Date: Fri, 9 Sep 2011 11:22:48 -0400	[thread overview]
Message-ID: <20110909152248.GA28480@sigill.intra.peff.net> (raw)
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.

> 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

      parent reply	other threads:[~2011-09-09 15:22 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-07 20:56 [PATCH 1/2] send-pack: typofix error message Junio C Hamano
2011-09-07 20:57 ` [PATCH 2/2] push -s: skeleton Junio C Hamano
2011-09-07 21:18   ` Shawn Pearce
2011-09-07 22:21     ` Junio C Hamano
2011-09-07 23:23       ` Shawn Pearce
2011-09-08 16:24         ` Junio C Hamano
2011-09-07 22:21   ` Nguyen Thai Ngoc Duy
2011-09-07 22:40     ` Junio C Hamano
2011-09-07 23:55   ` Robin H. Johnson
2011-09-08 20:03     ` Jeff King
2011-09-09  1:30       ` Robin H. Johnson
2011-09-09 16:03         ` Joey Hess
2011-09-09 16:14           ` Drew Northup
2011-09-09 19:12           ` Jeff King
2011-09-08  4:37   ` [PATCH 3/2] Split GPG interface into its own helper library Junio C Hamano
2011-09-08  4:38   ` [PATCH 4/2] push -s: send signed push certificate Junio C Hamano
2011-09-08  5:38     ` [PATCH 5/2] push -s: receiving end Junio C Hamano
2011-09-08  9:31       ` Johan Herland
2011-09-08 16:43         ` Junio C Hamano
2011-09-08 19:35   ` [PATCH 2/2] push -s: skeleton Jeff King
2011-09-08 20:48     ` Junio C Hamano
2011-09-08 21:02       ` Jeff King
2011-09-08 22:19         ` Junio C Hamano
2011-09-09 15:34           ` Jeff King
2011-09-09 17:32             ` Junio C Hamano
     [not found]         ` <CAJo=hJsQvRN3Z0xJg9q37Km1g_1qUdJKNQ6n8=a9mv3YjugyVw@mail.gmail.com>
2011-09-09 15:22           ` Jeff King [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110909152248.GA28480@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=spearce@spearce.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.