On Thu, Nov 10, 2011 at 18:18, Junio C Hamano <junio@xxxxxxxxx> wrote: > Johan Herland <johan@xxxxxxxxxxx> writes: > >> What about having one notes ref per branch? If/when the branch is merged, >> the associated notes ref containing the annotations for the commits on that >> branch would be merged as well (using "git notes merge"). > > That is a crude workaround that you could (with help from users) make it > work, but it does not change the fact that the current mechanism to > transfer and integrate notes across repositories is a bad match for what > the "signed commit" type annotations wants to achieve. In fact, the need > for such a workaround is an illustration of how bad a match the mechanism > is. > > When you merge a history that has commit A into another history that did > not have that commit, the act of creating a merge commit itself should be > enough to make the resulting history to contain that commit. The commit > DAG already expresses it, and if a parallel "notes" mechanism needs to be > futzed with to match that DAG, and command like "merge" needs to be told > to help that process, that is a shortcoming of the "notes" mechanism. [ ...and from elsewhere in this thread: ] > 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. Ok. Point taken. 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]. However, we could easily enough add a sorted list of (timestamp, annotated object name) pairs, to allow fast lookup of annotations created after a given timestamp. We could even store this list in a blob or tree object referenced directly from the notes tree [2]. Have fun! :) ...Johan [1]: Although I did at some point experiment with using timestamps in the internal organization of the notes tree (see for example http://article.gmane.org/gmane.comp.version-control.git/127966 ), I ended up using only the annotated object name (with flexible fanout). I don't think that reintroducing timestamps in the notes tree organization will pay off, because we need both lookup by annotated SHA1 and lookup by newer-than-given-timestamp to be fast, and there's AFAIK no way to get both from a single notes tree organzation. [2]: E.g. accessible with "git cat-file refs/notes/foo:timestamps". When a notes tree contains an entry that is obviously not an object name (SHA1), the notes code will leave it alone/untouched in the tree (see "struct non_note" and associated code in notes.c for further details). -- Johan Herland, <johan@xxxxxxxxxxx> www.herland.net -- 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
