On Sun, Feb 07, 2010 at 04:36:59PM +1100, Jon Seymour wrote: > As I see it, the existing use of notes is a special instance of a more > general metadata capability in which the metadata is constrained to be > a single blob. If notes continued to be constrained in this way, there > is no reason to change anything with respect to its current userspace > behaviour. That said, most of the plumbing which enabled notes could > be generalized to enable the arbitrary tree case [ which admittedly, I > have yet to sell successfully !] I do agree that storing trees is a natural generalization of the current notes implementation. Callers have to be made aware that they may see trees, of course, but you could probably "demote" trees into their representative sha1s for callers who were interested only in a blob form. But what I am concerned with is that generalizing may violate some assumptions made about how notes work. Notes trees can re-balance themselves to some degree, I thought (though I am pretty out of the loop on current notes developments). So during merges we need to normalize tree representations (though we probably already need to do that for the blob case). We would also need to do some magic with rename detection during merges. You would probably want rename detection _within_ a tree stored as a note for a particular commit, but not between notes stored for different commits. Or perhaps you would not even want to do a tree-merge between notes at all, and would rather see a conflict if two people noted two different trees. This would make sense to me if you were doing something like noting a build setup. If I note that commit X builds with a tree pointing to version Y of the build tools, and you note that it builds with version Z of the build tools, what should happen when we merge our notes? I can imagine wanting a conflict, and resolving it to Y or Z (perhaps whichever is more desirable). I can also see resolving it to Y _and_ Z (iow, treating it like a list). But doing a merge on the two trees of build tools (which are presumably somewhat immutable) is probably not helpful. Which to me argues in favor of adding the extra level of indirection. The note should store the tree sha1, and those who want to treat it as a tree can do so. Rename and merge issues just go away, as they operate on the tree sha1 and not on the tree itself. And of course the representation is just an implementation detail; you could still make a "git metadata" wrapper to transparently store trees from the user's perspective. The only complication is that git doesn't know to follow those sha1s for reachability analysis. In some cases that won't matter (like Junio's html/man example), but I suspect in some it will. Perhaps there is some way to flag the note entry as "this stores a sha1 that should be followed by fsck, but not otherwise dereferenced". I dunno. That is all just thinking out loud. It would help if we had some really detailed concrete examples of notes being used in practice. -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