Re: [PATCHv4 08/12] Teach the notes lookup code to parse notes trees with various fanout schemes

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