Re: [git patches] libata updates, GPG signed (but see admin notes)

[Junio C Hamano <gitster@pobox.com>]

Johan Herland <johan@herland.net> 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.