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? -- 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