I'm not tied to a particular implementation (not even mine), but we should think through the concept before baking something in. That was my impetus for throwing in a (half-baked) notes based solution before a config based is baked^Wset in stone ;) For me, commit annotations as currently implemented (notes) have the following positives: * easy ui (add/edit/copy) * easy scripting (-F/-m) * can be shared *if I want* (by pushing refspec; note that share=backup as well as share=publish, depending on where I push to); ui could be somewhat better * multiple sources possible * is versioned (ui could be better, e.g. git notes log) For branch annotations, I would want to have all of the above. Depending on the use case, I want to treat branch annotations as purely local (but may still want to push them to backup) or share and publish them. I might be interested in their history or not, etc. In addition, we would want to have the obvious: * git branch -m moves annotation * git branch --list --younameit shows annotation * etc. If we agree that we want the above properties (and that is a big if) then using notes seem very natural. [Having to rewrite an annotated tag object at each branch head change appears unnatural.] They should probably live in a separate default tree (one per remote for remote branches), and the actual mechanics (virtual objects, real objects, textconvcache like...) is not dictated by those requirements. Note though that we might be interested in annotating more general names than just refnames, e.g. paths, or names like "description". Since tags should be immutable, adding notes to a tag seems not much different from annotating the referenced commit, but it is different in concept and could be treated differently (as tag notes would be in a separate tree from the commit notes tree). So, if we want to keep that path open (annotate more general names), a mapping from names to notes becomes mandatory. Again, that does not dictate a specific implementation. Michael -- 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