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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html