On Thu, May 05, 2011 at 11:39:41AM -0400, Richard Peterson wrote: > > Â3. In git notes. You can do something like: > > > > Â Â Â (git rev-parse --verify HEAD > > Â Â Â Âecho "I reviewed this" > > Â Â Â ) | gpg --sign -a | > > Â Â Â git notes add -F - HEAD > > > > Â Â though you'd probably want to be a little more complex, and handle > > Â Â lists of signed notes for each commit. And you may want to store > > Â Â these in a separate notes ref from the default one. > > I had looked at this option, but had failed to see the usefulness of using > a different ref. I was worried about cluttering things up, overloading the > intended purpose of notes, and so forth. I wasn't really sure if notes were > intended to be general purpose storage for systematic, structured data. They are definitely intended to be general purpose storage. For one such (ab)use, see the textconv-caching subsystem. It maps binary blobs into their converted text counterparts. So we are keying on blobs (not commits!), and storing arbitrarily gigantic data in the notes values. And the nice thing is that because notes use git objects for storage, we get all the usual delta compression benefits on the result. > My inclination was to do this outside notes, or even in a parallel > implementation to notes, factoring out the common parts. I suppose that > looking at notes as somewhat of a free-for-all obviates this need. Is this > really what notes are for? Yep. Definitely use notes if you are going to do the storage in git. > > Â Â The advantage of notes are that they are designed for lots of > > Â Â per-commit storage, and can be accessed fairly efficiently. > > That was my other concern about notes - performance. Not sure how > notes are stored, but I certainly trust you that they're efficient. Each notes tree is stored as a git tree full of entries representing the commit (or other object) hashes. And each entry points to a blob which is the note's value. And then as the notes change over time, we version them with commit objects. So you can make notes and your coworker can make notes, and you can merge them together. For fun, you can do: # make a repo to play around in git clone /path/to/some/repo notes-test cd notes-test # make some notes. You could also use "notes add -F" # to add notes with arbitrary binary content. git notes --ref=foo add -m "this is note 1" HEAD git notes --ref=foo add -m "this is note 2" HEAD^ # check them out in context git log --show-notes=foo -2 # and then see how they're stored git checkout refs/notes/foo grep . * > > Developers would have to make a note and push their notes tree first, > > You mean for hook / verification purposes? Or is there some underlying > reason to push notes first? Yeah, for a pre-receive hook. You need to first tell the server "here are some signatures" by pushing the notes, and then it can verify those signatures when trying to put commits on actual branches. > I'll be sure to share. Great. I look forward to seeing the result. -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