Johan Herland <johan@xxxxxxxxxxx> writes: > 2. Simply decide on a constant 2/2/36 fanout. For the case with < 256K > notes, this is somewhat wasteful, but not prohibitively expensive. For the > case with > 64M notes, performance will start to degrade. The big advantage > with this approach is that when this is hardcoded into the notes code, we > have regained the property that notes for a given commit have exactly _one_ > unique position in the notes tree across all installations (enabling us to > fall back on the regular merge strategy). I thought it was Gitney who suggested to use a top-level fan-out based on the committer-date. If you typically have already parsed the commit when you want to look up notes objects for it, it won't have extra overhead, and when looking at only recent history it will only need to access a small subset of trees. I thought it was a neat idea (except that the question becomes what the granularity of the top level fan-out should be---one a day? one a month?---the optimum would depend on commit density). Was that idea shot down for some reason? -- 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