Hi, On Wed, 26 Aug 2009, Junio C Hamano wrote: > Johan Herland <johan@xxxxxxxxxxx> writes: > > > The semantics used when parsing notes trees (with regards to fanout subtrees) > > follow Dscho's proposal fairly closely: > > - No concatenation/merging of notes is performed. If there are several notes > > objects referencing a given commit, only one of those objects are used. > > - If a notes object for a given commit is present in the "root" notes tree, > > no subtrees are consulted; the object in the root tree is used directly. > > - If there are more than one subtree that prefix-matches the given commit, > > only the subtree with the longest matching prefix is consulted. This > > means that if the given commit is e.g. "deadbeef", and the notes tree have > > subtrees "de" and "dead", then the following paths in the notes tree are > > searched: "deadbeef", "dead/beef". Note that "de/adbeef" is NOT searched. > > - Fanout directories (subtrees) must references a whole number of bytes > > from the SHA1 sum they subdivide. E.g. subtrees "dead" and "de" are > > acceptable; "d" and "dea" are not. > > - Multiple levels of fanout are allowed. All the above rules apply > > recursively. E.g. "de/adbeef" is preferred over "de/adbe/ef", etc. > > If I am reading this correctly, the earlier parts of the series were > aiming to let multiple people to add notes to the same commit more or less > uncordinated while still allowing to merge them sensibly, but now such a > workflow becomes impossible with this change. > > The above claims notes trees with different levels of fan-out are allowed, > but what it really means is that merging notes trees with different levels > of fan-out will produce a useless result that records notes for the same > commit in different blobs all over the notes tree, and asking the notes > mechanism to give the notes for one commit will give only one piece that > originates in the tree whose creator happened to have used the longest > prefix while ignoring all others. It may _allow_ such a layout, but how > would such semantics be useful in the first place? > > I suspect that I am missing something but my gut feeling is that this > change turns an interesting hack (even though it might be expensive) into > a hack that is not useful at all in the real world, without some order, > discipline, or guideline is applied. > > What's the recommended way to work with this system from the end user's > point of view in a distirbuted environment? Somebody up in the project is > supposed to decide what fan-out is to be used for the whole project and > everybody should follow that structure? If a participant in the project > forgets that rule (or makes a mistake), a notes tree that mistakenly > merges his notes tree becomes practically useless? If so, perhaps we > would need a mechanism to avoid such a mistake from happening? Hmm... Maybe you're right (and mugwump was right all along) that _all_ matching notes should be shown... Ciao, Dscho -- 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