Johan Herland <johan@xxxxxxxxxxx> writes: > You would also have to keep track of deleted annotations, to enable the local > side to delete an annotation corresponding to an already-deleted annotation > on the remote side. For the "signed commit or pull request" use case, I think "delete" is probably not something you want to do in the first place. If there is a "certificate" that says "I made this commit" or "I agree this is a good topic to be merged to my history" that later turns out to be incorrect, you do not just want to excise it from your repository and the place you push to. You would instead want to distribute revocation notice for such certificiate, which would be a new "note" that will be attached to the commit or merge in question, so that other people who got the "certificate" from you or the place you push to will know about the removal using the same mechanism. Of course the "UI" layer could match a "certificate" and a "revocation" against each other and do something intelligent about them (like, not showing revoked ones by default), so in that sense a moral equivalent of "delete" from the end user's point of view can easily be supported [*1*]. Note that in this thread, I am not saying that "git notes" mechanism is not good for anything. A tree whose node names encode an object name is a valid way to store the mapping from that object to a set of other objects, and we already agreed that as the "local" storage mechanism, "git notes" may be used as-is for the purpose of this thread. But the transfer and merge semantics "git notes" mechanism offers treats the entire "notes" that appear in _one_ repository and merging that set to the entire "notes" in another repository and it is not a good match for the purpose of this thread. [Footnote] *1* The point is, it is not the only way to implement a "delete" to keep a history with common ancestor that has something and your latest that does not have that thing, which is what "git notes" gives you. If having to keep the history brings other undesired semantic baggage, other ways that do not have such undesired property need to be explored. -- 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