On Tue, Aug 11, 2020 at 04:51:19PM -0400, Taylor Blau wrote: > Many places in the code often need a pointer to the commit-graph's > 'struct bloom_filter_settings', in which case they often take the value > from the top-most commit-graph. > > In the non-split case, this works as expected. In the split case, > however, things get a little tricky. Not all layers in a chain of > incremental commit-graphs are required to themselves have Bloom data, > and so whether or not some part of the code uses Bloom filters depends > entirely on whether or not the top-most level of the commit-graph chain > has Bloom filters. > > This has been the behavior since Bloom filters were introduced, and has > been codified into the tests since a759bfa9ee (t4216: add end to end > tests for git log with Bloom filters, 2020-04-06). In fact, t4216.130 > requires that Bloom filters are not used in exactly the case described > earlier. > > There is no reason that this needs to be the case, since it is perfectly > valid for commits in an earlier layer to have Bloom filters when commits > in a newer layer do not. > > Since Bloom settings are guaranteed to be the same for any layer in a > chain that has Bloom data, Is it? Where is that guaranteed? > it is sufficient to traverse the > '->base_graph' pointer until either (1) a non-null 'struct > bloom_filter_settings *' is found, or (2) until we are at the root of > the commit-graph chain. > > Introduce a 'get_bloom_filter_settings()' function that does just this, > and use it instead of purely dereferencing the top-most graph's > '->bloom_filter_settings' pointer. > > While we're at it, add an additional test in t5324 to guard against code > in the commit-graph writing machinery that doesn't correctly handle a > NULL 'struct bloom_filter *'. > > Co-authored-by: Derrick Stolee <dstolee@xxxxxxxxxxxxx> > Signed-off-by: Taylor Blau <me@xxxxxxxxxxxx>
