On Tue, Oct 23, 2012 at 11:25:06PM +0200, Thomas Gleixner wrote: > > The resulting notes are stored in a separate revision-controlled branch > > Which branch(es) is/are that ? What are the semantics of that? They are stored in refs/notes/commits by default, but you can have multiple notes refs if you want to store logically distinct sets of notes. A notes ref's tree is just a tree whose entries are sha1s, and the file contents contain the notes themselves (the sha1s are broken down into subdirectories for performance, but "git notes" handles this behind the scenes). Technically you could check it out as a branch, edit, and commit, but "git checkout" is not happy to have a HEAD outside of refs/heads/, so you are stuck with plumbing like: $ git checkout `git rev-parse refs/notes/commits` $ edit edit edit $ git commit ... $ git update-ref refs/notes/commits HEAD It's probably not good for much beyond exploring how notes are implemented. See "git help notes" for more discussion. > Assume I commit something to branch "foo" > > Now I get that late Ack/Reviewed-by and want to associate that to that > commit in branch "foo". Does that go into "notes/foo" ? No. It would go into refs/notes/commits, or you could ask it to go to refs/notes/acks if you wanted to keep them separate from your default notes. It is indexed by commit object, not by branch (so if that branch later goes away, the notes are always still attached to the commit objects, assuming they got merged in). > Later when I send a pull request to my upstream maintainer for branch > "foo" does he get "notes/foo" automagically or do I have to request to > pull him that separately? No, he would have to pull your notes separately. Most of the discussion around sharing has been configuring the default refspec configuration to fetch notes. But in the kernel you guys use a lot of one-off pulls without configured remotes. I'm not sure what the right workflow would be. It might simply be to ask git to always pull particular notes commits at the same time (so you might push your notes to refs/notes/for-linus, and then git would automatically grab the notes when somebody pulls refs/heads/for-linus). > Either way is fine for me, though something which lets me "automate" > that would be appreciated. I can work around that easily as my pull > requests are generated via scripts, so I can add the secondary one for > the dependent "notes" branch if necessary. Though it would be nice to > avoid that. Avoiding that, i.e having a straight connection (maybe > configurable) between "foo" and "notes/foo" and the commits which have > not yet hit my upstream maintainer would make my life easier. I.e. I > just have to check "foo" for stuff which is not upstream yet instead > of checking both, but that might just be my laziness. > > Thoughts? That all makes sense. Putting extra work on the puller is not a good long-term solution. So while sending them an extra "also pull these notes" line, even if it ends up being a cut-and-pastable single-liner, is not great (even if it is the most flexible thing). Using a convention based on name-equivalence seems like a sensible compromise. -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