Johan Herland <johan@xxxxxxxxxxx> writes: > Given that we need an alternative way to transfer annotations between > repos (using auto-follow to select the relevant set of annotations, and > then transferring only those annotations): Can we leverage existing > functionality in "notes" where useful (e.g. using existing notes merge > strategies to deal with colliding annotations), while at the same time > extending the current "notes" feature with this alternative transfer > mechanism? FWIW, I expect there are other "notes" use cases that > would also prefer the auto-follow only-relevant transfer behavior. > > So, how can we use "notes" to better support the transfer semantics you > suggest? The mapping from the object being annotated to the annotation > object is already contained in the notes tree, but the "timestamp" you > describe (needed to efficiently calculate the set of annotations to > auto-follow) is not [1]. Please do not take the "timestamp" part too seriously. I am starting to think that what we want in this context actually is very close to annotated tags. I said we want a mapping from an annotated object to "a set of other objects" that annotate it, but it was an unnecessary and premature generalization. There is no reason that these annotations have to be structured "Git" objects such as blobs and trees. A set of annotated tags that have the same value on their "object" field is a perfect match for "a set of annotations attached to a given object". We already know that using the real tags has its own problems coming from having to give each and every one of them unique names somewhere in the refs hierarchy (be it refs/tags/ or refs/audit/), but imagine if we somehow had a way to: - keep these annotated tags in the object store; - keep them from getting pruned even if they are not referenced from anywhere in refs/ hierarchy; - given an object, efficiently enumerate such annotate tags that refer to the object. And then imagine that we are pushing history leading to a commit from one repository to another. Both repositories store these "anonymous" (that is what they are---they do not have a name in the refs/ hierarchy) tags. The two repositories can individually enumerate all these "anonymous" tags that annotate commits in the history that is being exchanged, and run a set reconciliation algorithm (e.g. [*1*]) to find out the anonymous tags that are missing from the recipient repository. Such an approach does not require any timestamp. My point is _not_ that the alternative in this message is superiour to the handwaving in my other message, but is that I think it may not be the best approach to think what needs to be added to "notes" to make it applicable for the problem we are solving. Rather, I think we should design how the overall system should look like (i.e. what property the resulting system should have) and then find out what is necessary in each part of the resulting solution (i.e. the list of "somehow had a way to..." above, plus "efficient set reconciliation"). [Footnote] *1* What's the Difference? Efficient Set Reconciliation without Prior Context http://cseweb.ucsd.edu/~fuyeda/papers/sigcomm2011.pdf -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
